1. Java异常处理的哲学基础

第一次接触Java异常处理时，我被那些繁琐的try-catch块搞得晕头转向。直到有一次线上事故，我才真正明白异常处理的价值所在。那天凌晨两点，服务器突然崩溃，而清晰的异常堆栈让我们在15分钟内就定位到了问题根源。

Java异常体系的核心在于可恢复性与编程错误的区分。Throwable作为所有异常和错误的基类，有两个直接子类：Error和Exception。Error代表JVM无法恢复的严重问题，比如OutOfMemoryError，我们通常不做处理。而Exception才是我们需要关注的重点。

Exception又分为两大类：

• Checked Exception（受检异常）：编译器强制要求处理的异常，比如IOException
• Unchecked Exception（非受检异常）：RuntimeException及其子类，比如NullPointerException

这里有个实用建议：把Checked Exception看作"业务异常"，把Unchecked Exception看作"代码缺陷"。比如读取文件时可能发生的FileNotFoundException就应该设计为Checked Exception，因为文件不存在时我们可以提示用户重新选择文件。而数组越界访问这类问题就应该用Unchecked Exception，因为这明显是程序员该修复的bug。

2. Checked与Unchecked的实战选择

在实际项目中，我见过太多滥用异常类型的案例。有个电商项目把库存不足设计成了RuntimeException，结果每次缺货都会导致订单流程中断，而不是优雅地提示用户。这就是典型的异常类型选择失误。

Checked Exception适用场景：

• 外部依赖不可控（文件I/O、网络调用）
• 业务规则校验（参数合法性检查）
• 需要用户干预的异常情况

// 正确的Checked Exception使用示例
public void processOrder(Order order) throws InsufficientStockException {
    if(!inventoryService.checkStock(order)){
        throw new InsufficientStockException("商品库存不足");
    }
    // 后续处理...
}

Unchecked Exception适用场景：

• 程序逻辑错误（空指针、数组越界）
• 不应该发生的状态（断言失败）
• 框架层面的错误（Spring的DataAccessException）

// 正确的RuntimeException使用示例
public void updateUser(User user) {
    if(user == null) {
        throw new IllegalArgumentException("用户对象不能为null");
    }
    // 更新逻辑...
}

团队规范建议：在项目启动时就制定《异常处理规范》，明确规定哪些业务场景使用哪种异常类型。我们团队规定所有业务异常必须继承自BaseBusinessException（自定义Checked Exception），而技术异常使用标准RuntimeException。

3. 异常封装的艺术

直接抛出底层异常是新手常犯的错误。有一次我们的支付服务抛出SQLException，前端同事一脸茫然：为什么支付会报数据库错误？这就是没有做好异常封装的典型例子。

异常封装三原则：

1. 语义对等：封装后的异常要与业务场景匹配
2. 信息完整：保留原始异常链（cause chain）
3. 适度抽象：不要过度封装失去调试价值

// 良好的异常封装示例
try {
    paymentService.process(payment);
} catch (SQLException e) {
    throw new PaymentFailedException("支付系统暂时不可用", e);
}

异常打印也有讲究。建议使用Slf4j的error方法打印完整堆栈：

try {
    // 业务代码
} catch (BusinessException e) {
    log.error("业务处理失败: {}", e.getMessage(), e);
    throw e;
}

注意避免的坑：

• 不要吞掉异常（空的catch块）
• 不要重复打印堆栈
• 不要用System.out打印异常（会影响日志顺序）

4. 异常处理的最佳实践

在微服务架构下，异常处理变得更加重要。我们的经验是建立统一的异常处理体系：

客户端友好异常：

@ExceptionHandler(BusinessException.class)
public ResponseEntity<ErrorResponse> handleBusinessException(BusinessException ex) {
    ErrorResponse response = new ErrorResponse(
        "BUSINESS_ERROR",
        ex.getLocalizedMessage()
    );
    return new ResponseEntity<>(response, HttpStatus.BAD_REQUEST);
}

服务端完整日志：

@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleUnexpectedException(Exception ex) {
    log.error("系统异常: {}", ex.getMessage(), ex);
    return new ResponseEntity<>(
        new ErrorResponse("SYSTEM_ERROR", "系统繁忙"),
        HttpStatus.INTERNAL_SERVER_ERROR
    );
}

实用技巧：

1. 为常见异常创建常量错误码
2. 在异常类中添加额外上下文字段
3. 使用@ControllerAdvice实现全局异常处理
4. 对第三方库的异常进行统一转换

5. 异常性能优化

很多人不知道异常处理是有性能成本的。在百万级QPS的系统中，不当的异常处理会导致明显的性能下降。

性能优化建议：

• 避免在循环中抛出异常
• 预检查代替异常捕获（比如先判断文件是否存在）
• 重用异常对象（对于频繁抛出的相同异常）
• 使用异常开关控制堆栈收集（适合生产环境）

// 性能优化示例
public void processBatch(List<Item> items) {
    ValidationResult result = validateItems(items);
    if(!result.isValid()) {
        throw new BatchProcessingException(result.getErrors());
    }
    // 正常处理...
}

实测数据显示：预先校验比捕获异常要快10-20倍。但也不要过度优化，只有在性能敏感的场景才需要考虑这些技巧。

6. 项目中的异常处理框架

在大型项目中，我推荐建立分层的异常体系：

BaseException
├── BaseBusinessException (Checked)
│   ├── ValidationException
│   ├── PaymentException
│   └── InventoryException
└── BaseSystemException (Unchecked)
    ├── ApiException
    └── DaoException

配套工具类建议包含：

• 异常构建器（ExceptionBuilder）
• 异常转换器（ExceptionTranslator）
• 上下文增强器（ContextEnhancer）
• 堆栈过滤器（StackFilter）

这样的架构既保证了灵活性，又保持了统一性。我们在多个百万级用户的项目中验证了这种设计的有效性。