WTF Solidity: Mastering Exception Handling with error, require, and assert【免费下载链接】WTF-SolidityWTF Solidity 极简入门教程供小白们使用。Now supports English! 官网: https://wtf.academy项目地址: https://gitcode.com/GitHub_Trending/wt/WTF-SoliditySolidity 智能合约一旦部署便不可篡改运行时的异常处理直接关系到资金安全与调试效率。本篇基于 WTF-Solidity 极简入门教程第 15 讲系统讲解 Solidity 抛出异常的三种方式——error、require与assert它们的语法、适用场景、底层行为差异以及基于 15_Errors/Error.sol 实测的 Gas 消耗对比。读完本文你将能够在自己的合约中根据是否携带参数、是否节省 Gas、是否面向用户等不同诉求正确选择最合适的异常抛出方式。异常在 Solidity 中的角色写智能合约经常会出现 bugSolidity 提供的异常命令error handling帮助开发者定位并处理这些问题。异常可能发生在编译期也可能发生在运行时。编译期异常由编译器在静态检查阶段发现而运行时异常则需要开发者在代码中主动声明检查条件与失败路径。在 Solidity 中运行时抛出的异常会使当前交易及其内部调用整体回滚revert状态变更被撤销已消耗的 Gas 按规则返还或扣除。本讲关注运行时异常处理核心是以下三种语句语句引入时机是否携带错误信息主要用途相对 Gas 消耗errorrevertSolidity 0.80.8.4 起正式支持自定义 error是可携带参数面向用户的业务异常官方推荐最低require0.8 之前即广泛使用是字符串消息可选通用条件校验带消息时最高assert长期存在否无消息开发者调试、内部不变量检查中等error 语句自定义错误与 reverterror是 Solidity 0.8.4 版本新增的特性用于高效省 Gas地向用户解释操作失败的原因同时还可以在抛出异常的同时携带参数帮助开发者更好地调试。它是目前官方推荐的首要异常抛出方式。定义自定义 error自定义 error 使用error关键字声明可以定义在合约内部也可以定义在合约外部文件顶层。下面在合约外部定义一个不带参数的TransferNotOwner异常当用户不是代币 owner 却尝试转账时抛出error TransferNotOwner(); // 自定义error也可以定义携带参数的异常在抛出时带上尝试转账的账户地址方便链上调试与前端展示error TransferNotOwner(address sender); // 自定义的带参数errorrevert 触发异常在执行中error必须搭配revert回退语句使用。以下transferOwner1()函数会检查代币的 owner 是否为发起人如果不是就revert抛出TransferNotOwner异常如果是则完成 owner 变更function transferOwner1(uint256 tokenId, address newOwner) public { if (_owners[tokenId] ! msg.sender) { revert TransferNotOwner(); // revert TransferNotOwner(msg.sender); } _owners[tokenId] newOwner; }带参数的版本只需把revert TransferNotOwner()改为revert TransferNotOwner(msg.sender)异常数据中即会包含发起人地址。相比下面要讲的requireerror的优势在于错误数据以紧凑的 ABI 编码存储selector 参数不会随消息长度线性增长同时仍能向用户传达失败原因。require 语句传统条件校验require是 Solidity 0.8 版本之前抛出异常的常用方法目前很多主流合约仍在使用它。它的使用方式为require(检查条件, 异常的描述)当检查条件不成立时抛出异常require(_owners[tokenId] msg.sender, Transfer Not Owner);require的优点是语法简单、语义直白非常适合前置条件校验如权限校验、参数校验、余额校验。其缺点是描述异常的字符串会完整存储在 revert 数据中Gas 消耗随字符串长度增加而线性增长比error命令要高。用require重写transferOwner1得到transferOwner2function transferOwner2(uint256 tokenId, address newOwner) public { require(_owners[tokenId] msg.sender, Transfer Not Owner); _owners[tokenId] newOwner; }assert 语句调试与不变量检查assert一般用于程序员写程序时 debug因为它不能解释抛出异常的原因比require少个字符串。用法很简单assert(检查条件)当检查条件不成立时抛出异常assert(_owners[tokenId] msg.sender);用assert重写transferOwner1得到transferOwner3function transferOwner3(uint256 tokenId, address newOwner) public { assert(_owners[tokenId] msg.sender); _owners[tokenId] newOwner; }assert的语义更适合表达内部不变量被破坏这类不应发生的状态例如算术溢出、逻辑漏洞导致的非法状态。它的异常信息是固定长度的Panic(uint256)错误码无法自定义内容因此不适合直接暴露给用户。源码级实现Error 合约剖析完整的可运行示例位于 15_Errors/Error.sol合约结构如下源码注释中还标注了在 Remix 中实测的 Gas 数据// SPDX-License-Identifier: MIT pragma solidity ^0.8.34; // 自定义error error TransferNotOwner(); contract Errors { // 一组映射记录每个TokenId的Owner mapping(uint256 address) private _owners; // Error方法: gas cost 24457 // Error with parameter: gas cost 24660 function transferOwner1(uint256 tokenId, address newOwner) public { ... } // require方法: gas cost 24755 function transferOwner2(uint256 tokenId, address newOwner) public { ... } // assert方法: gas cost 24473 function transferOwner3(uint256 tokenId, address newOwner) public { ... } }关键实现要点状态设计合约用mapping(uint256 address) private _owners记录每个 TokenId 的 Owner。由于映射初始值为address(0)只要用任意非 0 地址调用转账函数三个校验函数都会命中非 owner分支并抛出异常从而便于在 Remix 中复现。三种写法等价transferOwner1ifrevert、transferOwner2require 消息、transferOwner3assert实现的是完全相同的校验逻辑可以对照观察三种异常抛出方式的差异。编译环境说明源码注释标明 Gas 数据是在 Remix 中使用 0.8.17 版本编译、以tokenId 123和任意非 0 地址为参数测试得到的。仓库同时维护了中文版 15_Errors/readme.md 与英文版 Languages/en/15_Errors_en/readme.md 两份讲解文档内容互相印证。Remix 上机验证部署Errors合约后按以下步骤验证三种异常抛出方式输入任意uint256数字和非 0 地址error方法调用transferOwner1()控制台抛出异常并显示自定义的TransferNotOwner若带参数版本则同时显示触发者的地址require方法调用transferOwner2()控制台抛出异常并打印出require中的字符串Transfer Not Ownerassert方法调用transferOwner3()控制台只抛出异常没有任何自定义错误消息三种方法的 Gas 对比通过 Remix 控制台的 Debug 按钮可以查询每次函数调用的 Gas 消耗。使用 0.8.17 版本编译实测结果如下error方法 Gas 消耗24457加入参数后 Gas 消耗24660require方法 Gas 消耗24755assert方法 Gas 消耗24473可以看出当require带有字符串 message 时error方法 Gas 最少其次是assertrequire方法消耗 Gas 最多。因此error既可以告知用户抛出异常的原因又能省 Gas是业务异常抛出的首选。需要注意的是由于部署测试时间的不同每个函数的 Gas 消耗会有所不同但比较结果是一致的。补充说明 1require 不带 message 的情况若require不带 message如require(condition)其 Gas 消耗反而低于assert——因为不带 message 的revert返回空数据而assert会返回固定 36 字节的Panic(uint256)错误数据。但此时两者都无法告知用户异常原因实际开发中仍推荐使用error。补充说明 20.8.0 之前的 assert 行为在 Solidity 0.8.0 之前的版本中assert抛出的是一个 panic exception会把剩余的 Gas 全部消耗不会返还。0.8.0 之后则统一为标准的异常回滚语义。因此在使用旧版本编译器时要特别注意assert的高昂成本。实战选型建议综合语法、可读性与 Gas 表现在真实合约开发中可遵循以下选型原则业务校验、权限控制、面向用户失败原因优先使用errorrevert可携带结构化参数如账户地址、金额Gas 最优错误数据紧凑快速前置条件检查、临时脚本或简单合约require依然可用但尽量缩短错误消息字符串避免不必要的 Gas 开销若完全不需要消息可考虑无 message 的require内部不变量、溢出等绝不应发生的状态使用assert其Panic错误码语义明确适合作为逻辑防线。总结本讲介绍了 Solidity 中三种抛出异常的方法error、require和assert并通过 15_Errors/Error.sol 中三个等价的transferOwner函数对比了三者的 Gas 消耗。结论是error既能告知用户抛出异常的原因又能节省 Gas是 Solidity 0.8 时代的推荐实践require简单直观但带消息时成本最高assert无消息、适合内部调试与不变量检查。三种方式各司其职理解它们的差异是写出安全、高效、可调试合约的基础。【免费下载链接】WTF-SolidityWTF Solidity 极简入门教程供小白们使用。Now supports English! 官网: https://wtf.academy项目地址: https://gitcode.com/GitHub_Trending/wt/WTF-Solidity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考