aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorchriseth <chris@ethereum.org>2016-08-19 17:43:33 +0800
committerGitHub <noreply@github.com>2016-08-19 17:43:33 +0800
commit32c93cf9c9fca4ea1331d1a089bc492f47122ce2 (patch)
treebe723b1d40920fca97c79bc6c645fa17181f8e03
parentc282ab379aac4a6b14f59a957c6261e2edb8b1ce (diff)
parentbbe7c493adaf7b1d37310ad3d18e2a716f3b6713 (diff)
downloaddexon-solidity-32c93cf9c9fca4ea1331d1a089bc492f47122ce2.tar.gz
dexon-solidity-32c93cf9c9fca4ea1331d1a089bc492f47122ce2.tar.zst
dexon-solidity-32c93cf9c9fca4ea1331d1a089bc492f47122ce2.zip
Merge pull request #920 from Denton-L/document-throwing
Add documentation about throwing
-rw-r--r--docs/control-structures.rst7
1 files changed, 5 insertions, 2 deletions
diff --git a/docs/control-structures.rst b/docs/control-structures.rst
index 5b78d099..73b0131f 100644
--- a/docs/control-structures.rst
+++ b/docs/control-structures.rst
@@ -299,11 +299,14 @@ In the following example, we show how ``throw`` can be used to easily revert an
}
}
-Currently, there are three situations, where exceptions happen automatically in Solidity:
+Currently, there are six situations, where exceptions happen automatically in Solidity:
-1. If you access an array beyond its length (i.e. ``x[i]`` where ``i >= x.length``)
+1. If you access an array beyond its length (i.e. ``x[i]`` where ``i >= x.length``).
2. If a function called via a message call does not finish properly (i.e. it runs out of gas or throws an exception itself).
3. If a non-existent function on a library is called or Ether is sent to a library.
+4. If you divide or modulo by zero (e.g. ``5 / 0`` or ``23 % 0``).
+5. If you perform an external function call targeting a contract that contains no code.
+6. If a contract-creation call using the ``new`` keyword fails.
Internally, Solidity performs an "invalid jump" when an exception is thrown and thus causes the EVM to revert all changes made to the state. The reason for this 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 (or at least call) without effect.