处理非关键错误的正确方式

在软件开发中，处理非关键错误是提升代码健壮性的关键环节。当错误不影响核心业务流程，且调用方不关心具体失败细节时，应避免将错误向上层传递。本文提出“本地消化，全局监控”的处理哲学，强调在当前作用域内妥善处理非关键错误。核心策略包括：使用结构化日志库记录错误信息，便于后续问题排查；通过监控指标（如 Prometheus counter）聚合错误数据，掌握错误发生频率，及时发现问题趋势；提供优雅降级或默认值，保证核心功能可用性；以及考虑使用异步重试机制，增加系统健壮性。文章探讨了何时应忽略错误而非返回错误，强调保持代码健壮性的重要性，即使面对不关键的非关键错误，也应采取有效措施，确保程序稳定运行。

当错误不影响核心流程且调用方不关心时应本地处理而非返回——通过日志记录、监控指标、优雅降级或异步重试，确保问题可观测的同时程序继续运行。

当Golang中的一个函数遇到问题，但这个问题的严重程度不足以中断调用方的核心业务流程，或者说，调用方根本不关心这个具体的失败细节时，我们通常不会把这个错误作为返回值传递出去。相反，最直接且负责任的做法是：在当前作用域内妥善处理它——最常见的是记录日志，可能还会发送一些监控指标，然后让程序继续执行，就像什么都没发生过一样，至少从调用者的视角看是这样。

对于那些调用者不关心的非关键错误，我的处理哲学是“本地消化，全局监控”。这意味着错误不会向上冒泡到调用栈，但它也不会凭空消失。

核心策略包括：

1. 内部消化与日志记录： 这是最基本也是最重要的手段。当一个非关键错误发生时，立即使用结构化日志库（如 zap 或 logrus）将其记录下来。日志级别通常是 warn 或 error，具体取决于错误的潜在影响。关键在于日志中要包含足够的信息，比如错误类型、发生函数、相关输入参数（脱敏后）、甚至堆栈信息，以便后续排查。

   import (
       "fmt"
       "go.uber.org/zap" // 假设使用zap
   )
   
   var logger *zap.Logger // 全局或通过依赖注入获取
   
   func init() {
       // 示例初始化，实际项目中会更复杂
       l, _ := zap.NewProduction()
       logger = l
   }
   
   func saveOptionalPreference(userID string, prefData []byte) {
       // 假设这是一个可选的用户偏好保存操作
       err := someDatabaseCall(userID, prefData)
       if err != nil {
           // 调用者不关心这个保存是否成功，但我们不能完全忽略
           logger.Warn("Failed to save optional user preference",
               zap.String("userID", userID),
               zap.Error(err),
               zap.Stack("stacktrace"), // 添加堆栈信息便于调试
           )
           // 不返回错误，函数继续执行或正常退出
           return
       }
       // ... 继续其他操作
   }

   这里的关键是 logger.Warn 或 logger.Error，它会把问题记录下来，但不会中断 saveOptionalPreference 的执行流程。

2. 发出监控指标： 光有日志还不够。很多时候，我们希望通过聚合数据来发现问题趋势，而不是被单个错误日志淹没。对于非关键错误，可以递增一个指标计数器（例如 Prometheus counter）。这能让我们在不影响程序主流程的前提下，掌握这类错误的发生频率，并在达到一定阈值时触发告警。

   import (
       "github.com/prometheus/client_golang/prometheus"
       "github.com/prometheus/client_golang/prometheus/promauto"
   )
   
   var (
       optionalPreferenceSaveErrors = promauto.NewCounter(prometheus.CounterOpts{
           Name: "app_optional_preference_save_errors_total",
           Help: "Total number of errors saving optional user preferences.",
       })
   )
   
   func saveOptionalPreferenceWithMetrics(userID string, prefData []byte) {
       err := someDatabaseCall(userID, prefData)
       if err != nil {
           logger.Warn("Failed to save optional user preference",
               zap.String("userID", userID),
               zap.Error(err),
           )
           optionalPreferenceSaveErrors.Inc() // 递增错误计数器
           return
       }
       // ...
   }

   通过这种方式，我们可以通过Grafana仪表盘观察到偏好保存失败的趋势，而不是被每条日志打扰。

3. 提供优雅降级或默认值： 如果非关键错误导致某个可选数据无法获取或处理，可以考虑提供一个合理的默认值，或者返回一个空集。这保证了核心功能的可用性，即使某些边缘功能暂时受损。

4. 异步重试机制（可选）： 对于某些非关键操作，比如发送统计数据到第三方服务，如果失败了，可以考虑将其放入一个消息队列，由后台worker进行异步重试，而不是在当前请求路径中阻塞或直接放弃。这增加了系统的健壮性，同时避免了对主流程的干扰。

什么时候我们应该“忽略”一个错误，而不是返回它？

这其实是个艺术活儿，没有一刀切的答案，更多的是

到这里，我们也就讲完了《处理非关键错误的正确方式》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于日志记录,监控指标,非关键错误,本地消化,全局监控的知识点！