diff options
author | chriseth <chris@ethereum.org> | 2017-09-12 17:32:46 +0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2017-09-12 17:32:46 +0800 |
commit | fabf4accd3fe5b38068ee1ef30a637ae297a00bd (patch) | |
tree | feeaf30c01ffd1820151d86efd1d135e9b49c0e4 /docs | |
parent | fbe24da159452f8b22206b6e750174ed03b43ade (diff) | |
parent | 2b88eeb37039e8cb2639a3ad294739278673aefc (diff) | |
download | dexon-solidity-fabf4accd3fe5b38068ee1ef30a637ae297a00bd.tar.gz dexon-solidity-fabf4accd3fe5b38068ee1ef30a637ae297a00bd.tar.zst dexon-solidity-fabf4accd3fe5b38068ee1ef30a637ae297a00bd.zip |
Merge pull request #2870 from aarongoa/develop
Add payable constructor for `C` - #2869
Diffstat (limited to 'docs')
-rw-r--r-- | docs/control-structures.rst | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/docs/control-structures.rst b/docs/control-structures.rst index 05254903..0497365b 100644 --- a/docs/control-structures.rst +++ b/docs/control-structures.rst @@ -206,7 +206,7 @@ Those names will still be present on the stack, but they are inaccessible. return k; } } - + .. index:: ! new, contracts;creating @@ -237,16 +237,17 @@ creation-dependencies are not possible. D newD = new D(arg); } - function createAndEndowD(uint arg, uint amount) { + function createAndEndowD(uint arg, uint amount) payable { // Send ether along with the creation 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, -but it is not possible to limit the amount of gas. If the creation fails -(due to out-of-stack, not enough balance or other problems), an exception -is thrown. +As seen in the example, it is possible to forward Ether while creating +an instance of ``D`` using the ``.value()`` option, but it is not possible +to limit the amount of gas. +If the creation fails (due to out-of-stack, not enough balance or other problems), +an exception is thrown. 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. 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. -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. 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:: 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 of an exception instead of "bubbling up". |