cerc-io/solidity
16
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #2870 from aarongoa/develop

Browse Source 
Add payable constructor for `C` - #2869
This commit is contained in:
chriseth 2017-09-12 11:32:46 +02:00 committed by GitHub
commit fabf4accd3
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/control-structures.rst
View File

@ -206,7 +206,7 @@ Those names will still be present on the stack, but they are inaccessible.
return k; return k;
} }
} }
.. index:: ! new, contracts;creating .. index:: ! new, contracts;creating
@ -237,16 +237,17 @@ creation-dependencies are not possible.
D newD = new D(arg); D newD = new D(arg);
} }
function createAndEndowD(uint arg, uint amount) { function createAndEndowD(uint arg, uint amount) payable {
// Send ether along with the creation // Send ether along with the creation
D newD = (new D).value(amount)(arg); D newD = (new D).value(amount)(arg);
} }
} }
As seen in the example, it is possible to forward Ether to the creation using the ``.value()`` option, As seen in the example, it is possible to forward Ether while creating
but it is not possible to limit the amount of gas. If the creation fails an instance of ``D`` using the ``.value()`` option, but it is not possible
(due to out-of-stack, not enough balance or other problems), an exception to limit the amount of gas.
is thrown. If the creation fails (due to out-of-stack, not enough balance or other problems),
an exception is thrown.
Order of Evaluation of Expressions Order of Evaluation of Expressions
================================== ==================================
@ -382,7 +383,7 @@ Solidity uses state-reverting exceptions to handle errors. Such an exception wil
state in the current call (and all its sub-calls) and also flag an error to the caller. state in the current call (and all its sub-calls) and also flag an error to the caller.
The convenience functions ``assert`` and ``require`` can be used to check for conditions and throw an exception The convenience functions ``assert`` and ``require`` can be used to check for conditions and throw an exception
if the condition is not met. The ``assert`` function should only be used to test for internal errors, and to check invariants. if the condition is not met. The ``assert`` function should only be used to test for internal errors, and to check invariants.
The ``require`` function should be used to ensure valid conditions, such as inputs, or contract state variables are met, or to validate return values from calls to external contracts. The ``require`` function should be used to ensure valid conditions, such as inputs, or contract state variables are met, or to validate return values from calls to external contracts.
If used properly, analysis tools can evaluate your contract to identify the conditions and function calls which will reach a failing ``assert``. Properly functioning code should never reach a failing assert statement; if this happens there is a bug in your contract which you should fix. If used properly, analysis tools can evaluate your contract to identify the conditions and function calls which will reach a failing ``assert``. Properly functioning code should never reach a failing assert statement; if this happens there is a bug in your contract which you should fix.
There are two other ways to trigger exceptions: The ``revert`` function can be used to flag an error and There are two other ways to trigger exceptions: The ``revert`` function can be used to flag an error and
@ -392,7 +393,7 @@ in a call to ``revert``. The ``throw`` keyword can also be used as an alternativ
.. note:: .. note::
From version 0.4.13 the ``throw`` keyword is deprecated and will be phased out in the future. From version 0.4.13 the ``throw`` keyword is deprecated and will be phased out in the future.
When exceptions happen in a sub-call, they "bubble up" (i.e. exceptions are rethrown) automatically. Exceptions to this rule are ``send`` When exceptions happen in a sub-call, they "bubble up" (i.e. exceptions are rethrown) automatically. Exceptions to this rule are ``send``
and the low-level functions ``call``, ``delegatecall`` and ``callcode`` -- those return ``false`` in case and the low-level functions ``call``, ``delegatecall`` and ``callcode`` -- those return ``false`` in case
of an exception instead of "bubbling up". of an exception instead of "bubbling up".