异常处理中再抛异常是高危问题，易致无限递归、栈溢出、死锁或静默失败，尤其在日志、清理、恢复等环节；需通过禁抛检查异常、无副作用日志、熔断机制和隔离封装来防御。

异常处理逻辑内部再抛出异常，是高危但常被忽视的问题。它不一定会立刻崩溃，却可能引发无限递归、栈溢出、资源死锁或静默失败——尤其在日志、清理、恢复等环节嵌套出错时。

重入风险的典型触发场景

不是所有“异常中抛异常”都危险，但以下几类极易失控：

• 日志组件自身异常：比如在 catch 块里调用 logger.error(e)，而日志框架因配置错误、磁盘满、序列化失败又抛出 IOException 或 NullPointerException
• 资源清理代码出错：在 finally 或析构函数中 close() 文件/数据库连接，但连接已断开或句柄无效，再次触发异常
• 异常转换逻辑缺陷：将原始异常包装成业务异常时，构造函数中做了非幂等操作（如访问空对象、解析非法 JSON），导致二次崩溃
• 全局异常处理器嵌套：SpringMVC 的 @ControllerAdvice 捕获异常后，若其内部又抛出未被拦截的新异常，可能绕过统一处理链，甚至触发 DispatcherServlet 的默认错误页逻辑冲突

为什么容易演变成无限递归或死锁

关键在于异常传播路径与当前执行上下文的耦合：

• 若异常处理器本身依赖某个被污染的单例（如共享的线程不安全 logger），多线程并发下可能反复进入同一段有缺陷的处理逻辑
• C++ 中，若在析构函数（如 RAII 对象的 ~Resource()）里 throw 异常，而此时栈正在展开（stack unwinding），会直接调用 std::terminate —— 这不是死锁，而是强制终止，且无堆栈可查
• Java 中，如果 finally 块里抛出异常，它会压制 try/catch 中已捕获的原始异常；若该 finally 又被另一个异常处理器捕获，而该处理器的清理逻辑再出错……就形成隐式递归调用链
• Python 的 RLock 在异常处理中若误用（如在未持有锁时调用 release()），虽不直接死锁，但会抛出 RuntimeError，若该异常又被同一层的 except 捕获并尝试重试加锁，就可能陷入等待循环

真正有效的防御策略

重点不是“避免所有异常”，而是让异常处理本身具备抗扰动能力：

• 禁止在清理和日志路径中抛出检查型异常：Java 的 finally 块里不要 throw new IOException()；C++ 析构函数必须声明 noexcept（或显式 noexcept(true)）；Python 的 __exit__ 方法应吞掉内部异常并返回 False 表示不压制
• 日志优先使用无副作用方法：记录异常时，只调用 e.toString() 或 e.getMessage()，避免触发 e.getStackTrace()（可能触发 ClassLoader 错误）或 e.getCause().toString()（可能 cause 为 null 或递归引用）
• 为异常处理器设置熔断阈值：例如，监控 1 分钟内同一异常类型被处理超过 5 次，就临时禁用自定义 handler，降级到系统默认行为，防止雪崩
• 用静态/局部不可变对象隔离处理逻辑：比如把 logger 封装成 final static LogFacade，其内部对底层 logger 做 try-catch 包裹，任何异常都转为 printf 级别输出，绝不外泄

一个精简的安全模板（Java 示例）

以下是在 Service 层做异常包装时的推荐写法：

public Result findUser(int id) {
  try {
    return dao.selectById(id);
  } catch (DataAccessException e) {
    // 关键：构造响应时不访问任何外部状态
    String msg = "用户查询失败"; // 不拼接 e.getMessage()
    log.warn("DB error on user {}", id, e); // 日志在 catch 外侧，且 log 是防御封装过的
    return Result.fail(ErrorCode.USER_NOT_FOUND, msg);
  }
}