Intelligent Contract Language Solidity Tutorial Series 9-Error handling

This is the 9th article in the Solidity Tutorial series to introduce solidity error handling.
Solidity series complete list of articles please see the classification-solidity. It 's written in front .

Solidity is an intelligent contract programming language for Ethernet, you should have a better understanding of Ethernet and intelligent contracts before reading this article,
If you don't understand it, I suggest you look at the etheric square first.

Welcome to subscribe to the block chain technology column to read more comprehensive analysis articles. What is error handling

Error handling refers to the way in which errors are handled in a program, and solidity processing errors are not the same as our common language, solidity is the way to handle errors through a fallback state. An exception reverses the state of the current call (and all its child calls) and returns an error identity to the caller. Note that it is impossible to catch an exception , so there is no try ... catch ....

Why is it so designed for solidity to handle errors?
We can interpret the block chain as a distributed transactional database that is shared globally. Global sharing means that every person who participates in the network can read and write the records. If you want to modify the contents of this database, you must create a transaction, which means that the changes to be made (if we want to modify two values at the same time) can only be fully applied or not at all.
Students who have studied the database should understand the meaning of the business, if you are not very understanding of the word, suggest you search "database transactions."
Solidity error handling is to ensure that each invocation is transactional. How to handle

Solidity provides two function assert and require for condition checking, and throws an exception if the condition is not satisfied. The Assert function is commonly used to check (test) internal errors, while the Require function checks whether the input variable or contract state variable satisfies the condition and verifies that the call to the external contract return value.
In addition, if we use assert correctly, there is a solidity analysis tool that can help us to analyze the errors in the smart contract and help us find the bugs in the contract that are logically wrong.

In addition to the two functions assert and require to check the condition, there are two other ways to trigger the exception: the revert function can be used to mark the error and rollback the current invocation using throw Keyword throws an exception (from version 0.4.13), the throw keyword has been deprecated and will be eliminated in the future. ）

When an exception occurs in a child call, the exception is automatically bubbling up. There are exceptions, however: send, and the underlying function calls call, Delegatecall,callcode, when an exception occurs, these functions return FALSE.

Note: Calling the underlying function on a non-existent address Call,delegatecall,callcode also returns success, so we should always prioritize function checking when making calls.

An example below shows how to use require to check input conditions and assert for internal error checking:

pragma solidity ^0.4.0;

Contract Sharer {
    function sendhalf (address addr) public payable returns (UINT balance) {
        require (msg.value% 2 = 0); Allow even
        uint balancebeforetransfer = this.balance only;
        Addr.transfer (MSG.VALUE/2);  If it fails, an exception is thrown, and the following code is not an execution
        assert (this.balance = = BALANCEBEFORETRANSFER-MSG.VALUE/2);
        Return this.balance
    }
}

Let's actually run and see how the exception happens:

First Open remix, paste into the code, click Create Contract. The following figure:

Run Test 1: Append 1wei (odd) to invoke Sendhalf, an exception will occur, as shown in the following figure:

Run Test 2: Attach 2wei to call sendhalf and run normally. Run Test 3: Additional 2wei and Sendhalf parameters for the current contract itself, when the transfer is an exception, because the contract can not receive transfer, error prompted the image similar. Assert Type Exception

An Assert type exception is automatically generated in the following scenario: If the bounds are crossed, or if a negative ordinal value accesses the array, such as I >= x.length or i < 0 o'clock Access X[i] accesses a fixed-length bytesn if the ordinal is out of bounds, or a negative ordinal value. The divisor is 0, such as 5/0 or 23% 0. Move a negative value to a binary. such as:5< require type exception

An require type exception is automatically generated in the following scenario: Call Throw if the argument to require is False if you call a function by message, but in the process of calling, it does not end properly (gas is insufficient, There is no match to the corresponding function, or the called function has an exception. The underlying operations, except Call,send,delegatecall or Callcode, do not throw exceptions, but they represent failures by returning false. The reason for the 3rd article when you create a new contract using new is not done properly. If an external function call is invoked, the invoked object does not contain code. If the contract does not have the payable modifier public function when receiving the Ethernet currency (including constructors, and fallback functions). If the contract receives the Ethernet currency through a public getter function (public getter Funciton). If . Transfer () execution fails

When an exception of type require occurs, solidity performs a fallback operation (instruction 0xfd).
When an Assert type exception occurs, solidity performs an invalid operation (instruction 0xFE).
In both cases, the EVM will recall all state changes. It is because the expected results do not occur, there is no way to continue safe execution. The atomicity of the transaction must be guaranteed (consistency, or all of it, or no change at all, not just part of the change), so all operations need to be undone so that the entire transaction has no effect.

Note that an Assert type exception consumes all of the gas, and require does not consume gas from the metropolitan version (Metropolis, which is the current version of the main network). Reference Documents Solidity error Handling

Welcome to my knowledge planet. Block chain discussion block chain technology, at the same time I will provide you with the block chain technology solutions, as a star friend benefits, star friends can join the block chain technology paid Exchange group.
Simple block chain-system learning block chain, to create the best block chain technology blog.