How do you handle error-checking with require, assert, and revert?

Understanding Error-Handling Mechanisms in Solidity

In the world of blockchain development, particularly within the Ethereum ecosystem, writing secure and reliable smart contracts is paramount. One of the core aspects of ensuring contract integrity involves proper error handling. Solidity provides several built-in functions to manage errors: require, revert, and assert. Each serves a distinct purpose and is used under specific circumstances to maintain logic correctness and prevent unintended behavior.

Using require for Input and Condition Validation

The require statement is primarily employed to validate inputs, external conditions, or state requirements before executing critical operations. It ensures that certain preconditions are met, such as sufficient balances, correct sender roles, or valid timestamps. If the condition inside a require statement evaluates to false, the transaction is reverted, and any changes made during execution are undone. Importantly, require refunds unused gas to the caller, making it efficient for validating user inputs.

1. Use require to check function arguments like addresses or numerical values.
2. Validate access control by confirming msg.sender has the appropriate role.
3. Ensure time-based conditions are satisfied, such as checking block.timestamp against a deadline.
4. Confirm token allowances or balances before transferring assets.
5. Include descriptive strings in require statements to clarify the reason for failure.

Leveraging revert for Customized Error Handling

revert offers more granular control over error messages and conditions compared to require. While require automatically reverts when a condition fails, revert allows developers to trigger a revert at any point in the code with optional custom error messages. Since Solidity 0.8.4, developers can define custom error types using the error keyword, which saves gas by encoding errors more efficiently than string messages.

1. Define custom errors using the error keyword to reduce gas costs on reverts.
2. Call revert explicitly when complex logic determines an invalid state.
3. Use structured error types like InvalidAddress() or InsufficientFunds(uint) for clarity.
4. Trigger revert after detecting unexpected edge cases not covered by require.
5. Combine revert with modifiers to centralize validation logic across multiple functions.

Applying assert for Internal Invariant Checks

assert is reserved for checking internal invariants—conditions that should never be false if the code is correctly implemented. It indicates a bug in the contract if triggered. Unlike require, assert consumes all remaining gas when it fails and should only be used to detect unrecoverable errors such as arithmetic overflows (prior to Solidity 0.8) or unexpected changes in stored data. With newer versions of Solidity, many arithmetic issues are handled automatically, reducing the need for manual asserts.

1. Use assert to verify that a variable’s value remains within expected bounds after computation.
2. Check that critical storage variables have not been corrupted during execution.
3. Confirm unreachable code paths are indeed unreachable using assert(false).
4. Avoid using assert for input validation or external conditions—it's meant for internal consistency.
5. Understand that assert failures signal serious bugs requiring code fixes, not user corrections.

Frequently Asked Questions

What happens to gas when require fails?When a require statement fails, the transaction is reverted, and all state changes are rolled back. Unused gas is returned to the caller, minimizing cost for users who submit invalid inputs.

Can I use custom errors with require?No, require only accepts a boolean condition and an optional string message. To use custom error types defined with the error keyword, you must use revert instead.

Is assert still necessary in Solidity 0.8+?Its usage has diminished due to automatic overflow checks in Solidity 0.8 and above. However, it remains useful for verifying custom invariants or unexpected logical states that indicate a programming error.

Why choose revert over require?revert is chosen when you need to perform complex evaluations before deciding to abort execution or when leveraging custom errors for better readability and lower gas costs. It provides flexibility beyond the simple condition checking offered by require.