京东大佬问我，Java 异常处理的最佳实践与常见陷阱

嗯，用户问的是关于Java异常处理的最佳实践和常见陷阱。首先，我需要回忆一下自己学过的异常处理的知识，以及在实际开发中遇到的情况。可能用户是准备面试，或者在工作中遇到了问题，需要优化代码的异常处理部分。

首先，最佳实践方面，我记得应该包括如何正确地使用try-catch块，选择合适的异常类型，比如检查型异常和非检查型异常的区别。然后，异常封装，比如将低层异常包装成高层异常，避免暴露实现细节。还有资源管理，比如使用try-with-resources来自动关闭资源，避免资源泄漏。另外，避免捕获过于宽泛的异常，比如直接捕获Exception，这样可能会隐藏其他潜在的错误。记录日志也是重要的，应该在哪个层级处理异常时记录日志，避免重复记录。

常见陷阱的话，可能包括空的catch块，也就是捕获了异常却不做任何处理，这样问题被隐藏，难以调试。还有过度使用检查型异常，导致代码冗余，降低可读性。另外，在finally块中抛出异常，可能会覆盖原始的异常信息，导致问题难以追踪。还有，不正确的异常传播，比如在应该处理异常的地方却抛给了上层，或者反过来。

需要进一步确认的是，用户提到的京东大佬可能比较关注实际应用中的问题，比如高并发环境下的异常处理，或者微服务架构中的异常传递。可能需要结合具体的场景，比如分布式系统中的异常处理策略，或者如何设计自定义异常来提升系统的可维护性。

另外，可能需要注意一些细节，比如在抛出异常时保留原始异常的原因链，这样在排查问题时可以追溯到根源。还有，异常处理的性能问题，比如频繁地抛出异常可能会影响性能，应该避免在正常流程中使用异常控制逻辑。

总结起来，回答的结构应该分为最佳实践和常见陷阱两部分，每个部分列出几个关键点，并给出具体的例子和解决方案。需要确保内容全面，同时条理清晰，方便用户理解和应用。

Java 异常处理是代码健壮性的关键，但不当使用可能导致隐藏的 Bug 或性能问题。以下是经过实战验证的最佳实践和常见陷阱总结：

一、最佳实践（关键原则）

1.精准捕获异常类型

// 反例：捕获宽泛的 Exception
try { ... }
catch (Exception e) { ... } // 可能掩盖 NullPointerException 等非预期错误

// 正例：精准捕获
try { ... }
catch (FileNotFoundException e) { ... }
catch (IOException e) { ... }

2.异常分层处理

• DAO层：捕获 SQLException，转换为自定义 DataAccessException（避免污染业务层）
• Service层：抛出业务语义异常（如 OrderNotFoundException）
• Controller层：处理最终异常，返回用户友好的 HTTP 状态码

3.资源管理：try-with-resources

// 自动关闭资源（即使抛出异常）
try (FileInputStream fis = new FileInputStream("file.txt");
     BufferedInputStream bis = new BufferedInputStream(fis)) {
    // 操作资源
}

4.异常信息上下文化

throw new ServiceException("用户ID=" + userId + " 不存在", e); // 携带关键上下文

5.防御性 NPE 处理

// 使用 Objects.requireNonNull 提前拦截
public void process(User user) {
    this.user = Objects.requireNonNull(user, "User 对象不可为null");
}

6.自定义异常设计

• 继承 RuntimeException（避免过度检查型异常）
• 添加错误码字段，便于前端处理：

public class BusinessException extends RuntimeException {
    private final int errorCode;
    // 构造方法...
}

二、高频陷阱（避坑指南）

1.Swallowed Exception（异常吞噬）

try { ... }
catch (Exception e) {
    // 空catch块或仅打印e.printStackTrace()
}

后果：线上问题难以追踪
修复：至少记录日志或抛出自定义异常

2.Finally块中的异常覆盖

try { ... }
finally {
    // 如果close()抛出异常，可能覆盖try块中的原始异常
    resource.close(); 
}

解决方案：

try {
    try { ... }
    finally {
        resource.close(); // 处理关闭异常，保留原始异常
    }
} catch (IOException e) {
    throw new ResourceCloseException("关闭失败", e);
}

3.过度使用检查型异常

// 检查型异常强制调用方处理，但可能导致链式污染
public void readFile() throws IOException { ... }

优化：在框架层统一处理，避免业务代码充斥 try-catch

4.异常性能黑洞

// 在循环中使用异常做流程控制（极低效）
while (true) {
    try {
        parseData();
        break;
    } catch (ParseException e) { ... }
}

替代方案：用状态码或 Optional 提前校验

5.日志重复记录

// 底层记录日志后上层再次记录
catch (IOException e) {
    log.error("IO错误", e); // 底层记录
    throw new ServiceException("服务异常", e);
}

// Controller层再次记录同一个异常 → 日志冗余

原则：异常只记录一次（通常在最终处理层）

三、进阶技巧

1. JVM参数调优
   -XX:+HeapDumpOnOutOfMemoryError：内存溢出时自动生成堆转储
   -XX:ErrorFile=/logs/hs_err_pid%p.log：指定JVM崩溃日志路径
2. 全局异常处理器
   Spring 中使用 @ControllerAdvice 统一处理：

@ExceptionHandler(BusinessException.class)
public ResponseEntity handleBusinessEx(BusinessException ex) {
    return new ResponseEntity<>(ex.toErrorResponse(), HttpStatus.BAD_REQUEST);
}

3. 异步异常捕获
   CompletableFuture 需单独处理：

CompletableFuture.runAsync(task)
    .exceptionally(ex -> {
        log.error("异步任务失败", ex);
        return null;
    });

总结

• 核心哲学：异常应清晰表达故障原因，而非掩盖问题
• 黄金法则：
• 底层捕获技术异常，转换为业务语义异常
• 顶层处理用户交互，保证系统边界安全
• 终极目标：让异常日志成为排查问题的“导航仪”，而非“迷宫”