修复失败的场景几乎每个开发者都遇到过：程序突然崩溃，控制台只留下一句冷冰冰的报错信息；或者线上服务出现异常，翻遍日志却找不到任何有价值的线索。这类问题的根源往往不在于bug本身有多复杂，而在于异常处理和日志记录做得不到位，导致故障现场没有被完整保留下来。本文将围绕这两个核心环节展开，探讨如何建立一套可靠的机制，让修复失败的问题变得有迹可循。
异常处理中的常见错误做法
很多修复失败的案例，追根溯源都是异常处理写错了。最典型的问题就是“吞异常”：捕获了异常却什么都不做，代码看起来运行正常，实际上错误被悄悄隐藏了。比如下面这段Java代码：
try {
parseConfig(filePath);
} catch (Exception e) {
// 什么都不做，问题被隐藏
}这种写法的危害在于，当配置解析失败时，程序会带着错误状态继续运行，后续产生的现象与真正的出错点相距甚远。等你在几百行之外发现数据不对劲时，已经很难关联回最初的问题了。正确的做法至少要把异常记录下来，并根据业务决定是继续降级运行还是快速失败。
第二个常见错误是捕获范围过大。有些开发者习惯直接捕获Exception甚至Throwable，认为这样最安全。实际上这会把本不该处理的错误也拦截住，比如把InterruptedException吞掉会破坏线程的中断机制，把OutOfMemoryError捕获住会让JVM在濒临崩溃时还继续执行业务逻辑。捕获异常应该遵循精确原则，只捕获你知道如何处理的异常类型，其余的让它向上传播，交给顶层统一处理。
第三个问题是异常信息丢失。在捕获异常后抛出新的业务异常时，如果不传入原始异常对象，堆栈信息就会断裂。正确写法应该像下面这样，把原始异常作为cause传递：
try {
orderService.createOrder(request);
} catch (SQLException e) {
// 保留原始异常链，堆栈信息不丢失
throw new OrderCreateException("创建订单失败，订单号：" + request.getOrderNo(), e);
}如何设计合理的异常层级结构
当项目规模变大后，随手抛出RuntimeException会让调用方无法区分错误类型。建议根据业务域定义异常基类，再派生出具体的业务异常，形成清晰的层级结构。这样做的好处是，顶层处理器可以按异常类别统一处理，比如业务异常返回友好提示，系统异常触发告警。
设计异常类时还应注意携带足够的上下文信息。一个只有message的异常对象，排查价值非常有限。理想的业务异常应该包含错误码、关键业务参数、发生时间等信息，这些数据既方便日志系统结构化采集，也便于监控平台按错误码做聚合统计，快速发现高频故障点。
另外要区分“可恢复异常”和“不可恢复异常”。可恢复异常比如网络抖动导致的超时，可以通过重试机制处理；不可恢复异常比如参数校验失败，重试多少次都没有意义，应该立即失败并返回明确错误。混用两类异常会导致系统在无效重试上浪费资源，甚至引发雪崩效应。
日志记录的关键策略
有了合理的异常处理，还需要配套的日志记录才能形成完整的排查闭环。首先是要正确使用日志级别：DEBUG用于开发调试细节，生产环境一般关闭；INFO记录关键业务节点；WARN表示潜在风险但不影响主流程；ERROR只留给需要人工介入的问题。最常见的错误是把ERROR当万能级别使用，最终告警泛滥，真正的严重故障被淹没在噪音里。
其次，记录异常时务必把异常对象作为最后一个参数传给日志方法，而不是手动拼接message。对比下面两种写法：
// 错误写法：堆栈信息丢失
logger.error("处理失败：" + e.getMessage());
// 正确写法：完整打印堆栈
logger.error("处理订单失败，订单号：{}", orderNo, e);第一种写法只保留了message字符串，堆栈信息完全丢失，而堆栈恰恰是定位问题最关键的线索。第二种写法使用了占位符语法，既避免了不必要的字符串拼接开销，又保证了完整的异常上下文被记录。
日志内容本身也要讲究策略。一条有价值的日志应该包含足够的上下文：请求标识、用户标识、关键业务参数等。建议为每个请求生成唯一的traceId，并在整条调用链路中透传，所有日志都带上这个id。这样当用户反馈问题时，只需拿到traceId就能检索出完整的一次请求轨迹，无需在海量日志中盲目翻找。
异常与日志配合的实战方案
最后把两者结合起来看一个完整的处理模型。在应用的最外层（比如全局异常处理器或中间件）统一捕获异常，记录包含完整上下文的ERROR日志，并按异常类型决定响应方式。而在各层内部，只捕获并处理自己有能力处理的异常，处理不了的原样上抛，同时在关键路径上记录INFO级别的过程日志。
以一个典型的Web服务为例，分层职责可以这样划分：数据访问层在捕获数据库异常时转换为本系统的数据访问异常并保留cause；业务层记录关键决策点的日志，捕获可恢复异常时执行重试并记录WARN；接口层的全局异常处理器统一兜底，记录ERROR日志并返回规范化的错误响应。这样当修复失败的问题出现时，你既能在ERROR日志里看到最终的异常全貌，也能顺着INFO日志还原出故障前的执行路径。
此外，建议定期对日志做治理：检查是否有吞异常的代码（可以通过静态分析工具扫描空catch块）、是否有多余的printStackTrace调用、日志格式是否统一。日志治理和代码重构一样，应该成为持续性工作，而不是等到出故障后才临时补救。建立起这套机制后，再遇到修复失败的情况，你面对的将不再是黑盒，而是一条条清晰的线索。