Are there any downsides to if...else logic versus rejecting in a function

Question

Pretty much all examples of contract functions I see use the require(...) pattern. If the initial condition is not as expected, an error is thrown and the transaction is reverted.

I don't like this pattern because the consumer will not know why they got an error, especially if the function logic is complex. Is there any downside to simply using if...else + events instead?

Instead of:

function AddUser(address _user) {
    require(!userExists(_user));
    ... add the user ...
}

I would do:

function AddUser(address _user) returns (bool) {
    if (userExists(_user)) {
        UserExistsEvent(_user);
        return false;
    } else {
        ... add the user ...
        return true;
    }
}

This way the caller will know exactly what happened in the callee function (by return value and/or event) instead of getting some generic error.

Am I missing something? Why are most functions I see follow the require/throw pattern instead? Is it cheaper?

Answer 1

Since it's very hard to write correct smart contract code, and the consequences of writing incorrect smart contract code can be very bad, you generally want to optimize for the simplest source code, and the simplest code execution path.

require() is shorter and clearer than an if... return flow, and also reduces the amount that the caller has to get right, as returning a value requires them to correctly catch the return value and respond appropriately.

Not only that, when the caller handles an error, they usually want to do this with a revert, as this can be guaranteed not to leave any side effects. If the caller reverts, you also lose your event log entry, so you didn't gain anything from the extra complexity.

If you're going to end up reverting then there is also a slight gas benefit to doing it as soon as possible, but the difference is usually fairly small and in most cases it's a less important motivation than making the code simpler and harder to use wrongly.

However, returning a result is easier to handle if the calling contract usually wants to continue operation even if it fails, so in those circumstances it is often better to use if... return.