The try/catch syntax introduced in 0.6.0 is arguably the biggest leap in error handling capabilities in Solidity, since reason strings for revert and require were released in v0.4.22. Both try and catch have been reserved keywords since v0.5.9 and now we can use them to handle failures in external function calls without rolling back the complete transaction (state changes in the called function are still rolled back, but the ones in the calling function are not).

We are moving one step away from the purist "all-or-nothing" approach in a transaction lifecycle, which falls short of practical behaviour we often want.

Handling external call failures

The try/catch statement allows you to react on failed external calls and contract creation calls, so you cannot use it for internal function calls. Note that to wrap a public function call within the same contract with try/catch, it can be made external by calling the function with this..

The example below demonstrates how try/catch is used in a factory pattern where contract creation might fail. The following CharitySplitter contract requires a mandatory address property _owner in its constructor.

pragma solidity ^0.6.1;

contract CharitySplitter {
    address public owner;
    constructor (address _owner) public {
        require(_owner != address(0), "no-owner-provided");
        owner = _owner;
    }
}

There is a factory contract — CharitySplitterFactory which is used to create and manage instances of CharitySplitter. In the factory we can wrap the new CharitySplitter(charityOwner) in a try/catch as a failsafe for when that constructor might fail because of an empty charityOwner being passed.

pragma solidity ^0.6.1;
import "./CharitySplitter.sol";
contract CharitySplitterFactory {
    mapping (address => CharitySplitter) public charitySplitters;
    uint public errorCount;
    event ErrorHandled(string reason);
    event ErrorNotHandled(bytes reason);
    function createCharitySplitter(address charityOwner) public {
        try new CharitySplitter(charityOwner)
            returns (CharitySplitter newCharitySplitter)
        {
            charitySplitters[msg.sender] = newCharitySplitter;
        } catch {
            errorCount++;
        }
    }
}

Note that with try/catch, only exceptions happening inside the external call itself are caught. Errors inside the expression are not caught, for example if the input parameter for the new CharitySplitter is itself part of an internal call, any errors it raises will not be caught. Sample demonstrating this behaviour is the modified createCharitySplitter function. Here the CharitySplitter constructor input parameter is retrieved dynamically from another function — getCharityOwner. If that function reverts, in this example with "revert-required-for-testing", that will not be caught in the try/catch statement.

function createCharitySplitter(address _charityOwner) public {
    try new CharitySplitter(getCharityOwner(_charityOwner, false))
        returns (CharitySplitter newCharitySplitter)
    {
        charitySplitters[msg.sender] = newCharitySplitter;
    } catch (bytes memory reason) {
        ...
    }
}
function getCharityOwner(address _charityOwner, bool _toPass)
        internal returns (address) {
    require(_toPass, "revert-required-for-testing");
    return _charityOwner;
}

Retrieving the error message

We can further extend the try/catch logic in the createCharitySplitter function to retrieve the error message if one was emitted by a failing revert or require and emit it in an event. There are two ways to achieve this:

1. Using catch Error(string memory reason)

function createCharitySplitter(address _charityOwner) public {
    try new CharitySplitter(_charityOwner) returns (CharitySplitter newCharitySplitter)
    {
        charitySplitters[msg.sender] = newCharitySplitter;
    }
    catch Error(string memory reason)
    {
        errorCount++;
        CharitySplitter newCharitySplitter = new
            CharitySplitter(msg.sender);
        charitySplitters[msg.sender] = newCharitySplitter;
        // Emitting the error in event
        emit ErrorHandled(reason);
    }
    catch
    {
        errorCount++;
    }
}

Which emits the following event on a failed constructor require error:

CharitySplitterFactory.ErrorHandled(
    reason: 'no-owner-provided' (type: string)
)

2. Using catch (bytes memory reason)

function createCharitySplitter(address charityOwner) public {
    try new CharitySplitter(charityOwner)
        returns (CharitySplitter newCharitySplitter)
    {
        charitySplitters[msg.sender] = newCharitySplitter;
    }
    catch (bytes memory reason) {
        errorCount++;
        emit ErrorNotHandled(reason);
    }
}

Which emits the following event on a failed constructor require error:

CharitySplitterFactory.ErrorNotHandled(
  reason: hex'08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000116e6f2d6f776e65722d70726f7669646564000000000000000000000000000000' (type: bytes)

The above two methods for retrieving the error string produce a similar result. The difference is that the second method does not ABI-decode the error string. The advantage of the second method is that it is also executed if ABI decoding the error string fails or if no reason was provided.

Future plans

There are plans to release support for error types meaning we will be able to declare errors in a similar way to events allowing us to catch different type of errors, for example:

catch CustomErrorA(uint data1) { … }
catch CustomErrorB(uint[] memory data2) { … }
catch {}