The attempt/catch syntax launched in 0.6.0 is arguably the most important leap in error dealing with capabilities in Solidity, since purpose strings for revert and require had been launched in v0.4.22. Each attempt and catch have been reserved key phrases since v0.5.9 and now we are able to use them to deal with failures in exterior operate calls with out rolling again the entire transaction (state adjustments within the known as operate are nonetheless rolled again, however the ones within the calling operate aren’t).
We’re shifting one step away from the purist “all-or-nothing” method in a transaction lifecycle, which falls wanting sensible behaviour we frequently need.
Dealing with exterior name failures
The attempt/catch assertion means that you can react on failed exterior calls and contract creation calls, so you can not use it for inside operate calls. Be aware that to wrap a public operate name inside the similar contract with attempt/catch, it may be made exterior by calling the operate with this..
The instance under demonstrates how attempt/catch is utilized in a manufacturing unit sample the place contract creation would possibly fail. The next CharitySplitter contract requires a compulsory deal with property _owner in its constructor.
pragma solidity ^0.6.1; contract CharitySplitter { deal with public proprietor; constructor (deal with _owner) public { require(_owner != deal with(0), "no-owner-provided"); proprietor = _owner; } }
There’s a manufacturing unit contract — CharitySplitterFactory which is used to create and handle cases of CharitySplitter. Within the manufacturing unit we are able to wrap the new CharitySplitter(charityOwner) in a attempt/catch as a failsafe for when that constructor would possibly fail due to an empty charityOwner being handed.
pragma solidity ^0.6.1; import "./CharitySplitter.sol"; contract CharitySplitterFactory { mapping (deal with => CharitySplitter) public charitySplitters; uint public errorCount; occasion ErrorHandled(string purpose); occasion ErrorNotHandled(bytes purpose); operate createCharitySplitter(deal with charityOwner) public { attempt new CharitySplitter(charityOwner) returns (CharitySplitter newCharitySplitter) { charitySplitters[msg.sender] = newCharitySplitter; } catch { errorCount++; } } }
Be aware that with attempt/catch, solely exceptions occurring contained in the exterior name itself are caught. Errors contained in the expression aren’t caught, for instance if the enter parameter for the new CharitySplitter is itself a part of an inside name, any errors it raises won’t be caught. Pattern demonstrating this behaviour is the modified createCharitySplitter operate. Right here the CharitySplitter constructor enter parameter is retrieved dynamically from one other operate — getCharityOwner. If that operate reverts, on this instance with “revert-required-for-testing”, that won’t be caught within the attempt/catch assertion.
operate createCharitySplitter(deal with _charityOwner) public { attempt new CharitySplitter(getCharityOwner(_charityOwner, false)) returns (CharitySplitter newCharitySplitter) { charitySplitters[msg.sender] = newCharitySplitter; } catch (bytes reminiscence purpose) { ... } } operate getCharityOwner(deal with _charityOwner, bool _toPass) inside returns (deal with) { require(_toPass, "revert-required-for-testing"); return _charityOwner; }
Retrieving the error message
We are able to additional prolong the attempt/catch logic within the createCharitySplitter operate to retrieve the error message if one was emitted by a failing revert or require and emit it in an occasion. There are two methods to attain this:
1. Utilizing catch Error(string reminiscence purpose)
operate createCharitySplitter(deal with _charityOwner) public { attempt new CharitySplitter(_charityOwner) returns (CharitySplitter newCharitySplitter) { charitySplitters[msg.sender] = newCharitySplitter; } catch Error(string reminiscence purpose) { errorCount++; CharitySplitter newCharitySplitter = new CharitySplitter(msg.sender); charitySplitters[msg.sender] = newCharitySplitter; // Emitting the error in occasion emit ErrorHandled(purpose); } catch { errorCount++; } }
Which emits the next occasion on a failed constructor require error:
CharitySplitterFactory.ErrorHandled( purpose: 'no-owner-provided' (kind: string) )
2. Utilizing catch (bytes reminiscence purpose)
operate createCharitySplitter(deal with charityOwner) public { attempt new CharitySplitter(charityOwner) returns (CharitySplitter newCharitySplitter) { charitySplitters[msg.sender] = newCharitySplitter; } catch (bytes reminiscence purpose) { errorCount++; emit ErrorNotHandled(purpose); } }
Which emits the next occasion on a failed constructor require error:
CharitySplitterFactory.ErrorNotHandled( purpose: hex'08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000116e6f2d6f776e65722d70726f7669646564000000000000000000000000000000' (kind: bytes)
The above two strategies for retrieving the error string produce an analogous end result. The distinction is that the second technique doesn’t ABI-decode the error string. The benefit of the second technique is that it’s also executed if ABI decoding the error string fails or if no purpose was supplied.
Future plans
There are plans to launch help for error sorts that means we can declare errors in an analogous strategy to occasions permitting us to catch completely different kind of errors, for instance:
catch CustomErrorA(uint data1) { … } catch CustomErrorB(uint[] reminiscence data2) { … } catch {}