Learn how to control code flow in Solidity.
Solidity supports many familiar control structures, but these come with additional restrictions and considerations due to the cost of gas and the necessity of setting a maximum amount of gas that can be spent in a given transaction.
By the end of this lesson you should be able to:
if
, else
, while
, and for
require
to write a function that can only be used when a variable is set to true
revert
statement to abort execution of a function in a specific stateerror
to control flow more efficiently than with require
Solidity supports the basic conditional and iterative control structures found in other curly bracket languages, but it does not support more advanced statements such as switch
, forEach
, in
, of
, etc.
Solidity does support try
/catch
, but only for calls to other contracts.
Yul is an intermediate-level language that can be embedded in Solidity contracts and is documented within the docs for Solidity. Yul does contain the switch
statement, which can confuse search results.
The if
, else if
, and else
, statements work as expected. Curly brackets may be omitted for single-line bodies, but we recommend avoiding this as it is less explicit.
The while
, for
, and do
, keywords function the same as in other languages. You can use continue
to skip the rest of a loop and start the next iteration. break
will terminate execution of the loop, and you can use return
to exit the function and return a value at any point.
You can use console.log
by importing import "hardhat/console.sol";
. Doing so will require you to mark otherwise pure
contracts as view
.
Solidity contains a set of relatively unique, built-in functions and keywords to handle errors. They ensure certain requirements are met, and completely abort all execution of the function and revert any state changes that occurred during function execution. You can use these functions to help protect the security of your contracts and limit their execution.
The approach may seem different than in other environments. If an error occurs partly through a high-stakes transaction such as transferring millions of dollars of tokens, you do not want execution to carry on, partially complete, or swallow any errors.
The revert
keyword halts and reverses execution. It must be paired with a custom error
. Revert should be used to prevent operations that are logically valid, but should not be allowed for business reasons. It is not a bug if a revert
is triggered. Examples where revert
and error
would be used to control operations include:
Custom error
s can be declared without parameters, but they are much more useful if you include them:
When triggered, the error
provides the values in the parameters provided. This information is very useful when debugging, and/or to transmit information to the front end to share what has happened with the user:
You’ll also encounter revert
used as a function, returning a string error. This legacy pattern has been retained to maintain compatibility with older contracts:
The error provided is less helpful:
The require
function is falling out of favor because it uses more gas than the pattern above. You should still become familiar with it because it is present in innumerable contracts, tutorials, and examples.
require
takes a logical condition and a string error as arguments. It is more gas efficient to separate logical statements if they are not interdependent. In other words, don’t use &&
or ||
in a require
if you can avoid it.
For example:
The output error message will be the first one that fails. If you were to submit 1
, and 3
to this function, the error will only contain the first message:
The assert
keyword throws a panic
error if triggered. A panic
is the same type of error that is thrown if you try to divide by zero or access an array out-of-bounds. It is used for testing internal errors and should never be triggered by normal operations, even with flawed input. You have a bug that should be resolved if an assert throws an exception:
The output here isn’t as helpful, so you may wish to use one of the patterns above instead.
In this lesson, you’ve learned how to control code flow with standard conditional and iterative operators. You’ve also learned about the unique keywords Solidity uses to generate errors and reset changes if one of them has been triggered. You’ve been exposed to both newer and legacy methods of writing errors, and learned the difference between assert
and require
.