异常处理不当会破坏系统稳定性。空指针未捕获导致线程崩溃；泛化捕获（如catch(Exception)）掩盖问题；finally中抛异常会覆盖原始异常；应使用Objects.requireNonNull、具体异常类型捕获、try-with-resources及完整日志。

异常处理本身不提升稳定性，滥用或忽略它反而直接破坏稳定性。

空指针异常没捕获就崩溃

Java 运行时遇到 NullPointerException 且未被任何 catch 捕获时，线程立即终止，如果发生在主线程或关键工作线程中，整个服务可能不可用。

• 常见于对 Map.get()、Optional.get()、第三方 SDK 返回值不做判空就直接调用方法
• 日志里只看到 Exception in thread "main" java.lang.NullPointerException，但没上下文，修复困难
• 正确做法不是到处加 try-catch，而是用 Objects.requireNonNull() 或提前返回，让问题在更早、更明确的位置暴露

catch (Exception e) 吞掉所有异常

这是稳定性杀手。它掩盖真实错误，导致状态不一致、资源泄漏、下游持续失败却无人知晓。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 比如数据库连接异常被吞掉，后续所有 DAO 调用都返回空或默认值，业务逻辑照常走完，但数据根本没写入
• catch (Exception e) 会捕获 RuntimeException（如 ArrayIndexOutOfBoundsException）和受检异常，完全失去异常分类意义
• 应按需捕获具体异常类型：用 catch (SQLException e) 处理数据库问题，用 catch (IOException e) 处理文件或网络问题，并至少记录 e.getMessage() 和堆栈

finally 里没做资源清理的边界情况

即使写了 finally，若其中抛出新异常，会覆盖原始异常，导致真正问题被隐藏。

立即学习“Java免费学习笔记（深入）”；

• 典型场景：InputStream.close() 在 finally 中执行，但 IO 异常被抛出，而原始的 ParseException 就消失了
• JDK 7+ 推荐用 try-with-resources，自动调用 close() 且不会压制原始异常
• 自定义资源类必须实现 AutoCloseable，否则无法用于该语法

最危险的不是没写异常处理，而是写了“看起来能跑”的异常处理——比如空 catch 块、泛化捕获、日志不打堆栈、忽略返回码。稳定性来自对每个异常路径的明确决策，而不是让程序“不报错”。