研发协作
实现错误处理、设计API或提升应用可靠性时…
在开发新功能、设计容错API或排查生产问题时,系统化地处理可恢复与不可恢复错误并避免常见陷阱。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
实现错误处理、设计API或提升应用可靠性通用
解决思路
- 根据错误类型选择处理方式:异常用于意外错误和异常条件;Result类型用于预期错误和校验失败;panic/崩溃用于不可恢复错误和程序bug;错误码为C风格需自律;Option/Maybe类型用于可空值。
- 区分错误类别:可恢复错误包括网络超时、文件缺失、无效用户输入、API限流;不可恢复错误包括内存耗尽、栈溢出、程序bug(如空指针)。
- 快速失败:尽早校验输入,尽早失败。
- 保留上下文:包含堆栈跟踪、元数据、时间戳。
- 编写有意义的错误消息:说明发生了什么以及如何修复。
- 合理记录日志:错误才记录日志,预期内的失败不要刷屏日志。
- 在正确的层级处理:只在能真正有意义地处理错误的地方捕获。
- 清理资源:使用 try-finally、上下文管理器、defer。
- 不要吞掉错误:要么记录日志要么重新抛出,不要静默忽略。
- 使用类型安全的错误:尽可能使用带类型的错误。
- 包装外部服务错误时保留原始异常(如 Python 的 raise ... from e),并附上 service、details 等元数据。
- 对已知的应用错误直接重新抛出,对意外错误记录 logger.exception 后包装为应用错误再抛出。
- 避免捕获过宽(如 except Exception 会隐藏bug)。
- 避免空的 catch 块静默吞掉错误。
- 避免既记录日志又重新抛出导致重复日志条目。
- 避免忘记关闭文件、连接等资源。
- 避免无用的错误消息(如“Error occurred”)。
- 避免返回错误码,改用异常或 Result 类型。
- 避免忽略异步错误(如未处理的 promise rejection)。