异常处理不当会破坏系统稳定性。空指针未捕获导致线程崩溃；泛化捕获（如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) 吞掉所有异常
这是稳定性杀手。它掩盖真实错误，导致状态不一致、资源泄漏、下游持续失败却无人知晓。
- 比如数据库连接异常被吞掉，后续所有 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 块、泛化捕获、日志不打堆栈、忽略返回码。稳定性来自对每个异常路径的明确决策，而不是让程序“不报错”。
