mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
Review suggestions.
This commit is contained in:
parent
7f05ef8aca
commit
64067975e4
@ -376,7 +376,7 @@ series of function calls that will reach a failing assertion. If this is possibl
|
|||||||
in your contract you should fix.
|
in your contract you should fix.
|
||||||
|
|
||||||
There are two other ways to trigger execptions: The ``revert`` function can be used to flag an error and
|
There are two other ways to trigger execptions: The ``revert`` function can be used to flag an error and
|
||||||
revert the current call. In the future, it migt be possible, to also include details about the error
|
revert the current call. In the future, it might be possible, to also include details about the error
|
||||||
in a call to ``revert``. The ``throw`` keyword can also be used as an alternative to ``revert()``.
|
in a call to ``revert``. The ``throw`` keyword can also be used as an alternative to ``revert()``.
|
||||||
|
|
||||||
When exceptions happen in a sub-call, they "bubble up" automatically. Exceptions to this rule are ``send``
|
When exceptions happen in a sub-call, they "bubble up" automatically. Exceptions to this rule are ``send``
|
||||||
@ -430,4 +430,4 @@ Internally, Solidity performs a revert operation (instruction ``0xfd``) for a ``
|
|||||||
the EVM to revert all changes made to the state. The reason for reverting is that there is no safe way to continue execution, because an expected effect
|
the EVM to revert all changes made to the state. The reason for reverting is that there is no safe way to continue execution, because an expected effect
|
||||||
did not occur. Because we want to retain the atomicity of transactions, the safest thing to do is to revert all changes and make the whole transaction
|
did not occur. Because we want to retain the atomicity of transactions, the safest thing to do is to revert all changes and make the whole transaction
|
||||||
(or at least call) without effect. Note that ``assert``-style exceptions consume all gas available to the call, while
|
(or at least call) without effect. Note that ``assert``-style exceptions consume all gas available to the call, while
|
||||||
``revert``-style exceptions will not consume any gas starting from the metropolis release.
|
``revert``-style exceptions will not consume any gas starting from the Metropolis release.
|
@ -130,8 +130,8 @@ This means that, for example, ``keccak256(0) == keccak256(uint8(0))`` and
|
|||||||
|
|
||||||
It might be that you run into Out-of-Gas for ``sha256``, ``ripemd160`` or ``ecrecover`` on a *private blockchain*. The reason for this is that those are implemented as so-called precompiled contracts and these contracts only really exist after they received the first message (although their contract code is hardcoded). Messages to non-existing contracts are more expensive and thus the execution runs into an Out-of-Gas error. A workaround for this problem is to first send e.g. 1 Wei to each of the contracts before you use them in your actual contracts. This is not an issue on the official or test net.
|
It might be that you run into Out-of-Gas for ``sha256``, ``ripemd160`` or ``ecrecover`` on a *private blockchain*. The reason for this is that those are implemented as so-called precompiled contracts and these contracts only really exist after they received the first message (although their contract code is hardcoded). Messages to non-existing contracts are more expensive and thus the execution runs into an Out-of-Gas error. A workaround for this problem is to first send e.g. 1 Wei to each of the contracts before you use them in your actual contracts. This is not an issue on the official or test net.
|
||||||
|
|
||||||
.. _address_related:
|
|
||||||
.. index:: balance, send, transfer, call, callcode, delegatecall
|
.. index:: balance, send, transfer, call, callcode, delegatecall
|
||||||
|
.. _address_related:
|
||||||
|
|
||||||
Address Related
|
Address Related
|
||||||
---------------
|
---------------
|
||||||
|
@ -886,7 +886,7 @@ bool ExpressionCompiler::visit(FunctionCall const& _functionCall)
|
|||||||
auto success = m_context.appendConditionalJump();
|
auto success = m_context.appendConditionalJump();
|
||||||
if (function.kind() == FunctionType::Kind::Assert)
|
if (function.kind() == FunctionType::Kind::Assert)
|
||||||
// condition was not met, flag an error
|
// condition was not met, flag an error
|
||||||
m_context << Instruction::INVALID;
|
m_context.appendInvalid();
|
||||||
else
|
else
|
||||||
m_context.appendRevert();
|
m_context.appendRevert();
|
||||||
// the success branch
|
// the success branch
|
||||||
|
@ -73,7 +73,7 @@ BOOST_AUTO_TEST_CASE(basic_compilation)
|
|||||||
Json::Value contract = result["contracts"]["fileA:A"];
|
Json::Value contract = result["contracts"]["fileA:A"];
|
||||||
BOOST_CHECK(contract.isObject());
|
BOOST_CHECK(contract.isObject());
|
||||||
BOOST_CHECK(contract["interface"].isString());
|
BOOST_CHECK(contract["interface"].isString());
|
||||||
BOOST_CHECK(contract["interface"].asString() == "[]");
|
BOOST_CHECK_EQUAL(contract["interface"].asString(), "[]");
|
||||||
BOOST_CHECK(contract["bytecode"].isString());
|
BOOST_CHECK(contract["bytecode"].isString());
|
||||||
BOOST_CHECK_EQUAL(
|
BOOST_CHECK_EQUAL(
|
||||||
dev::test::bytecodeSansMetadata(contract["bytecode"].asString()),
|
dev::test::bytecodeSansMetadata(contract["bytecode"].asString()),
|
||||||
|
Loading…
Reference in New Issue
Block a user