Rust开发中何时使用`expect`、何时主动返回错误？

可以安全使用expect的场景 #

• 逻辑上100%不可触发的错误分支：如果代码前置已经做了完备的校验，或者从业务逻辑上可以证明Option/Result绝对不会是None/Err，此时expect仅相当于带提示的断言，即使意外触发也属于逻辑bug，panic反而能第一时间暴露问题，避免带着错误状态继续运行产生更严重的后果。很多开源项目中附带qed（意为逻辑已证明）注释的expect都属于这类情况。
• 链下执行的代码逻辑：链下工作机、RPC接口处理、客户端工具、测试代码等场景的panic只会影响当前单次任务/请求，不会导致链出块中断，可以用expect简化非核心错误的处理逻辑，这也是parity-bridges-common、frontier等项目中expect写法占比高的主要原因。
• 链启动/创世初始化阶段的逻辑：创世配置加载、启动参数校验阶段的panic只会阻断链启动流程，不会影响上线后的链运行，提前暴露配置错误反而能规避上线后更大的故障。

必须主动返回错误、禁止使用expect的场景 #

• 用户可触发的链上Runtime逻辑：所有调度调用（extrinsic）中的逻辑分支，只要和用户输入、动态链上状态相关，都必须返回自定义的链上错误，绝对不能用expect。不可控的用户输入一旦触发panic会直接导致出块节点崩溃，引发链中断。
• 可预期的业务错误分支：余额不足、签名校验失败、跨链消息过期等属于正常业务流程内会出现的错误，必须返回明确的业务错误码方便上层调用方处理，不能用expect直接终止程序。
• 依赖外部不可控输入的逻辑：但凡错误触发条件和其他pallet状态、跨链消息内容、外部预言机输入等不可控因素相关，都必须做完整的错误处理，禁止用expect省略错误分支。

注意：如果看到开源项目中的expect没有附带逻辑安全说明，不要直接照搬，需要先判断对应代码的运行环境和前置校验逻辑是否完备，避免把风险带到自己的项目中。

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