异常处理是稳定性设计的骨架，需区分RuntimeException（不捕获，修复逻辑）、受检异常（必须显式处理）和业务异常（主动抛出）；用try-with-resources防资源泄漏；日志须保留异常链并脱敏敏感信息。
异常处理不是补丁，是稳定性设计的骨架
Java程序的健壮性不取决于“有没有 try-catch”，而取决于异常是否被当作控制流的一部分来设计。捕获 Exception 却不处理根本原因，或把 NullPointerException 吞掉再返回默认值，反而会掩盖故障点，让问题在下游爆发得更猛烈。
哪些异常该捕获？哪些该声明？哪些该炸掉？
区分三类异常是稳定性的起点：
-
RuntimeException及其子类（如IllegalArgumentException、ConcurrentModificationException）：代表编程错误或不可恢复状态，**不该捕获，应修复逻辑或提前校验** - 受检异常（
IOException、SQLException）：代表外部依赖可能失败，**必须显式处理——要么重试/降级，要么向上抛出并声明throws** - 自定义业务异常（如
InsufficientBalanceException）：**用throw new XxxException(...)主动抛出，而非靠 null 或 -1 传递错误语义**
try-with-resources 和 finally 不是语法糖，是资源泄漏的防线
文件句柄、数据库连接、网络 Socket 等资源未释放，会导致系统级不稳定（如 java.io.IOException: Too many open files）。手动写 finally 关闭容易遗漏或覆盖异常；try-with-resources 强制编译器检查 AutoCloseable 实现，并保证关闭逻辑执行，即使 try 块中已抛异常。
try (FileInputStream fis = new FileInputStream("data.bin");
BufferedInputStream bis = new BufferedInputStream(fis)) {
// 读取逻辑
} catch (IOException e) {
// 异常处理 —— fis 和 bis 已自动关闭
}
日志 + 异常链 = 故障定位的最小必要信息
只打 e.printStackTrace() 或 log.error("failed") 会让线上问题排查变成盲人摸象。关键点：
- 记录异常时，**必须保留原始异常对象**：
log.error("Failed to parse config", e)，而非log.error("Failed to parse config: " + e.getMessage()) - 封装异常时，**用构造函数传入 cause**：
throw new ServiceException("DB write failed", originalException)，避免断掉异常链 - 敏感字段（密码、token）不能进日志，但可打占位符：
log.warn("Auth failed for user, ip: {}", remo
teIp)
