第三部分：实战中最致命的坑 —— 异常传播的失败场景分析
在实际工业级开发中，80% 的异常处理故障，都是因为错误截断异常传播链路导致的。下面我将列举 4 种最常见的失败场景，这些场景在初级和中级开发者的代码中非常普遍，隐蔽性极强，也是线上故障的主要根源。
3.1 场景一：空 catch 块吃掉异常，完全丢失故障信号
这是最常见的错误：捕获异常后，catch块中没有任何处理逻辑，或者只有简单的日志打印，不重新抛出异常，直接截断异常传播链路。
错误代码示例
public void deleteUser(Long id) {   String sql = "DELETE FROM user WHERE id = ?";   try (Connection conn = DriverManager.getConnection(DB\_URL);   PreparedStatement pstmt = conn.prepareStatement(sql)) {   pstmt.setLong(1, id);   pstmt.executeUpdate();   } catch (SQLException e) {   // 空catch块，或仅打印一行日志，不重新抛出异常！   // 上层方法完全感知不到数据库删除操作的异常   e.printStackTrace();   } }故障影响：如果数据库删除操作抛出异常，比如约束冲突、集群同步失败，
catch块仅打印了异常栈信息，没有重新抛出异常；调用方在执行完
deleteUser()方法后，会默认觉得逻辑执行成功，继续执行后续的业务逻辑，导致数据不一致，甚至更严重的连锁故障。
3.2 场景二：捕获泛化的 Exception，掩盖重要业务异常
为了省事，很多开发者会直接捕获泛化的Exception类，而不是精准捕获具体的异常类型。这会导致一个严重的问题：将所有类型的异常，包括本该抛出的业务异常，都被错误地吃掉，无法区分异常类型。
错误代码示例
public User getUserById(Long id) {   try {   String sql = "SELECT \* FROM user WHERE id = ?";   // 执行数据库查询逻辑   return queryUserFromDb(id);   } catch (Exception e) {   // 捕获泛化的Exception，无法区分是「数据库异常」还是「参数校验异常」   return null;   } }故障影响：如果
queryUserFromDb()方法抛出
SQLException、
NullPointerException或
IllegalArgumentException，都会被同一个
catch块捕获。上层调用方拿到
null结果，完全无法区分是「数据不存在」还是「数据库操作失败」，更无法进行针对性的容错处理。
3.3 场景三：包装异常时丢失原始栈信息，无法定位故障根源
在分层架构中，我们经常需要将底层的检查型异常，包装为上层的非检查型异常，或者自定义的业务异常。但很多开发者在包装异常时，没有传入原始异常对象，导致丢失了完整的异常栈追踪信息，线上故障发生后，无法根据日志定位到异常的根本发生位置。
错误代码示例
public class UserService {   private UserDao userDao = new UserDao();   public User getUserById(Long id) {   try {   return userDao.queryUserById(id);   } catch (SQLException e) {   // 错误的包装方式：没有将原始异常e传入新的BusinessException中   // 导致原始异常的栈信息丢失，日志中只能看到BusinessException的抛出位置   throw new BusinessException("获取用户信息失败");   }   } }故障影响：线上故障发生后，查看错误日志，只能看到
BusinessException的异常栈信息，无法定位到是 DAO 层的哪一行代码抛出的原始
SQLException，以及具体的异常原因，比如哪条 SQL 语句执行失败、数据库返回的具体错误码是什么，增加了故障排查的难度。
3.4 场景四：在 finally 块中抛出异常，覆盖原始异常
这是一个隐蔽性极强的错误：在finally块中抛出新的异常，或者finally块中的代码本身抛出异常，会覆盖掉 try 块中原始的异常，导致上层调用方只能接收到finally块中的异常，丢失了原始的故障信号。
错误代码示例
public void updateUser(User user) throws SQLException {   try (Connection conn = DriverManager.getConnection(DB\_URL);   PreparedStatement pstmt = conn.prepareStatement(sql)) {   // 执行数据库更新逻辑   pstmt.executeUpdate();   } catch (SQLException e) {   throw e; // 重新抛出原始异常   } finally {   // 错误示范：finally块中的代码抛出了新的异常   closeConnection();   } } private void closeConnection() {   throw new RuntimeException("关闭数据库连接失败"); }故障影响：如果
try块中的数据库更新逻辑抛出了
SQLException，同时
finally块中的
closeConnection()方法也抛出了
RuntimeException，原始的
SQLException会被完全覆盖。上层调用方只能接收到「关闭数据库连接失败」的异常，看不到原始的报错信息，会误导故障排查方向，增加定位难度。
