Track 4 · Solidity foundations · lesson 8

require, revert, custom errors

9 min

A contract that fails quietly is worse than one that crashes. The caller is told everything worked, and finds out otherwise later — usually when the money is gone.

Safe.solRepair

Loading editor…

A stranger's withdrawal should fail loudly, not quietly.

Run the code to see what happens.

Nudge

Returning early does not fail. The caller is told everything went fine.

Show me the approach

You need the transaction to revert. Declare a custom error and revert with it.

Show me the code

Add `error NotOwner();` at contract level, then replace `return;` with `revert NotOwner();`.

Explain the solution

Custom errors are the cheapest way to fail — a four-byte selector instead of a whole string. `require(cond, "message")` works too but costs more gas and bloats the contract.

Revert undoes everything

When a transaction reverts, every state change it made is rolled back — including changes made before the failure, and changes made in other contracts it called along the way. The chain behaves as though the transaction only ever spent gas.

This is unusual and worth sitting with. There is no partial success. You never have to write cleanup code for a half-finished operation, because half-finished operations do not exist.

It also means a revert deep inside a chain of calls unwinds the whole thing — which is exactly what makes an external call that reverts a denial-of-service tool in the wrong hands.

Three ways to fail

require(amount > 0, "amount must be positive");   // check an input
revert NotOwner();                                 // custom error
assert(totalSupply >= balance);                    // invariant that must hold

require — validate inputs and conditions. Refunds unused gas.
revert with a custom error — the modern, cheapest form. A four-byte selector rather than a whole string stored in your bytecode.
assert — for things that should be impossible. A failing assert signals a bug in your code, not bad input.

Predict

Why do custom errors cost less gas than `require` with a message string?

The error string is stored in the contract's bytecode; a custom error is four bytesCustom errors skip the rollback, so less work is undonerequire is an old opcode that was never optimised

The failure you cannot see

Solidity's low-level .call() does not revert when the call it makes fails. It returns false, and if you ignore that return value your code carries on as though nothing happened.

(bool ok, ) = recipient.call{value: amount}("");
require(ok, "transfer failed");   // without this line, failure is silent

Forgetting that require is one of the most common real-world bugs in Solidity, and you will exploit it in track 7.

Check

A transaction updates three storage variables, then reverts. What is left behind?

The first two changes, since they happened before the failureNothing — every change is undone, but the gas is still spentNothing, and the gas is refunded too

Worth remembering

A revert undoes every state change in the transaction, including in contracts it called.
There is no partial success, so cleanup code for half-finished operations is unnecessary.
`require` for input validation, custom `error` + `revert` for the cheapest failures, `assert` for impossible conditions.
Custom errors are cheaper because a string lives in your bytecode and a selector is four bytes.
Low-level `.call()` returns false instead of reverting — ignoring that is a classic exploitable bug.