副标题 / 摘要

有些语言刻意不提供异常机制，转而使用错误码或 Result 类型。本文解释这样做的理由与工程影响。

目标读者

  • 需要在不同语言间迁移的开发者
  • 设计 API 的工程师
  • 关注可维护性的团队

背景 / 动机

异常能减少样板代码，但也容易隐藏控制流。
无异常的设计强调“错误即数据”，使失败路径显式可见。

核心概念

  • 异常机制：通过抛出异常改变控制流
  • 错误码/Result：显式返回错误
  • 失败路径显式化：让错误处理更可追踪

实践指南 / 步骤

  1. 为每个函数明确错误返回类型
  2. 用统一的错误模型（Result/Option）
  3. 在边界层做错误转换
  4. 对关键错误路径写测试

可运行示例

from typing import Tuple


def parse_int(s: str) -> Tuple[bool, int]:
    if s.isdigit():
        return True, int(s)
    return False, 0


if __name__ == "__main__":
    ok, val = parse_int("123")
    print(ok, val)
    ok, val = parse_int("x")
    print(ok, val)

解释与原理

无异常机制让错误路径显式化，便于审计与测试。
代价是调用者需要更多样板代码来处理失败。

常见问题与注意事项

  1. 错误码会不会被忽略？
    会，因此需要强制检查（类型系统/编码规范）。

  2. 异常就一定不好吗？
    不一定，关键在于规范与可观测性。

  3. Result 是否影响性能？
    通常影响可忽略，关键是可读性与一致性。

最佳实践与建议

  • 统一错误返回模型，减少混用
  • 保持错误信息可追踪、可定位
  • 边界层统一转换为用户可理解的错误

小结 / 结论

无异常机制让错误处理显式可控，但增加了调用成本。
工程上需要在可维护性与开发效率之间权衡。

参考与延伸阅读

  • Rust Error Handling
  • Go Error Handling Patterns

元信息

  • 阅读时长：6~8 分钟
  • 标签：错误处理、异常、Result
  • SEO 关键词：无异常机制, 错误码, Result
  • 元描述：解释无异常机制的优缺点与工程取舍。

行动号召（CTA）

选一个常见异常流程，尝试用显式返回值实现并比较可读性。