What is the advantage of using require instead of return or revert for error handling?

Question

As is well documented, require is preferred over assert for error conditions, eg. Difference between require and assert and the difference between revert and throw

Solidity might someday include the option to include error text in a require statement. (https://solidity.readthedocs.io/en/develop/control-structures.html#error-handling-assert-require-revert-and-exceptions)

However for the time being, revert/require results in the unhelpful message Error: VM Exception while processing transaction: revert, without even a line number.

One pattern involves events:

event Status(uint indexed statusCode);
...
if(someCondition) {
    Status('code');
    return;
 }

And the error code can be extracted from the transaction logs.

Another pattern using require:

if(someCondition) {
    Status('code');
    require(someCondition);
 }

Or:

if(someCondition) {
    Status('code');
    revert();
 }

Are all of these functionally identical? Is there a best practice?

Answer 1

Under the hood, require will revert the transaction, just like revert will. This means that the transaction will fail, and your event will not be logged.

return will not stop the transaction and will instead continue execution. If this is the function directly being called in the transaction, then the only difference is whether the transaction completes successfully or unsuccessfully. But if this function is being called by another function, possibly from a different contract, then return will allow code to continue executing.

As a rule of thumb, this is not a good idea, but under some circumstances where it really doesn't matter whether this code succeeded or failed, it could be okay.