Make createAndEndowD payable in contract creation example

This commit is contained in:
Aaron Colaço 2017-09-03 15:18:48 +05:30 committed by Alex Beregszaszi
parent bf294253bb
commit 2b88eeb370

View File

@ -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".