aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorAaron Colaço <aaroncolaco.work@gmail.com>2017-09-03 17:48:48 +0800
committerAlex Beregszaszi <alex@rtfs.hu>2017-09-12 17:07:54 +0800
commit2b88eeb37039e8cb2639a3ad294739278673aefc (patch)
treea5823fbbb29cf7d52cbf9e4905b553ad8af6b201 /docs
parentbf294253bb455a051c6e84bd95856dffab461b23 (diff)
downloaddexon-solidity-2b88eeb37039e8cb2639a3ad294739278673aefc.tar
dexon-solidity-2b88eeb37039e8cb2639a3ad294739278673aefc.tar.gz
dexon-solidity-2b88eeb37039e8cb2639a3ad294739278673aefc.tar.bz2
dexon-solidity-2b88eeb37039e8cb2639a3ad294739278673aefc.tar.lz
dexon-solidity-2b88eeb37039e8cb2639a3ad294739278673aefc.tar.xz
dexon-solidity-2b88eeb37039e8cb2639a3ad294739278673aefc.tar.zst
dexon-solidity-2b88eeb37039e8cb2639a3ad294739278673aefc.zip
Make `createAndEndowD` payable in contract creation example
Diffstat (limited to 'docs')
-rw-r--r--docs/control-structures.rst17
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".