Sui区块链Move智能合约错误类型的规范定义方法

你参考的官方NFT Marketplace示例中的错误定义写法，本身就是Sui Move生态规范的标准样例：

// 支付金额和预期不匹配时抛出
const EAmountIncorrect: u64 = 0;
// 非资产所有者尝试下架操作时抛出
const ENotOwner: u64 = 1;

以下针对两个核心疑问给出明确解答：

1. 错误常量的命名规则 #

以大写字母E开头，后续采用大驼峰格式是Move全生态（包括Sui官方框架、官方示例、主流开源合约）通用的惯用命名规范。
这个规则不是编译器强制要求的语法约束，是生态长期迭代形成的约定：

• 前缀E是Error的缩写，开发者读代码时可以一眼识别出该常量是错误码，和其他业务常量做区分
• 后续大驼峰的写法直接对应错误场景的语义，除了你示例中的两个常量，Sui框架中常见的EInsufficientBalance（余额不足）、ENotAuthorized（无权限）、EInvalidInput（输入参数非法）都严格遵循这个格式
  如果不按这个规则写，比如用全大写蛇形、小驼峰且开头不带E的写法，不会影响合约编译运行，但会大幅降低协作时的代码可读性，不符合生态开发习惯。

2. 同模块内重复分配相同u64错误码的影响 #

Move编译器不会对同模块内重复的错误码数值报编译错误，但会引发三个明确的问题：

• 链上排障完全失效：Sui交易执行失败抛出错误时，只会返回触发错误的模块标识 + 错误码u64数值，不会返回常量名。如果多个错误场景用同一个数值，交易报错时你根本无法定位到底是哪个逻辑分支触发的异常，线上问题排查成本会极高。
• 下游适配逻辑混乱：对接合约的前端、索引器、链上自动化脚本、多签校验逻辑，都是靠「模块地址+错误码」作为错误类型的唯一判断依据。重复错误码会导致错误提示、逻辑分支判断完全错乱，比如把越权操作的错误提示成付款金额错误，直接影响用户体验和业务逻辑正确性。
• 审计和维护成本提升：合约审计、后续迭代改bug时，重复的错误码会干扰审计人员和后续维护开发者的判断，增加引入新bug的概率。

补充实践提示：错误码不需要全局链上唯一，只要保证同一个模块内部的错误码数值不重复即可——因为错误返回时会附带模块信息，不会和其他模块的同数值错误码产生冲突。常规做法是同模块内错误码从0开始顺序递增赋值，不需要跳号，也不需要特意预留数值区间。

内容的提问来源于stack exchange，提问作者Kostas Kryptos