Java异常处理核心是明确责任边界：谁该处理、何时处理、如何恢复；finally仅用于确定性资源清理，不替代异常处理；应分层捕获具体异常并按语义响应，避免泛捕获和finally中return。
Java中异常处理的关键不是“捕获所有异常”，而是明确谁该处理、何时处理、如何恢复。finally不是兜底保险，而是资源清理的确定性保障——它执行与否只取决于JVM是否退出，与return、break、throw无关。
明确try-catch的责任边界
不要在业务方法里吞掉异常或打印后忽略。捕获异常的前提是：你有能力且应该对此做出响应。
- 底层I/O、网络调用抛出的受检异常（如IOException），应在靠近资源处捕获并转化为更语义化的业务异常（如FileLoadException），再向上抛出
- 运行时异常（如NullPointerException、IllegalArgumentException）通常反映逻辑缺陷，不应盲目catch，而应通过校验提前规避
- 顶层入口（如main、Controller方法）可统一捕获未处理异常，记录日志并返回友好提示，但不掩盖原始堆栈
finally中只做“必须执行”的清理动作
finally块适合释放资源、重置状态等不可跳过的操作，但要避免在此抛出新异常或修改返回值。
- 优先使用try-with-resources替代手动close——它自动在finally语义下调用close()，且能抑制关闭异常
- 若需手动清理（如解锁、关闭非AutoCloseable资源），确保finally内代码无异常，或用try-catch包裹清理逻辑本身
- 避免在finally里return或throw——它会覆盖try/catch中的返回值或异常，导致行为难以追踪
理解return与finally的执行顺序
即使try或catch中有return，finally仍会执行；但return表达式的值会在finally前“暂存”，finally中修改变量不影响已确定的返回值。
立即学习“Java免费学习笔记（深入）”；
- 以下代码返回10，不是20：
int m() { try { return 10; } finally { System.out.println("done"); } } - 若finally中也有return，则直接返回finally的值，丢弃try/catch中的返回——这是容易引发bug的设计，应禁止
- 若try中抛异常，finally执行完后原异常继续向上抛出；若finally也抛异常，则原异常被抑制（可通过getSuppressed()获取）
用具体类型代替Exception泛捕获
catch (Exception e) 看似省事，实则掩盖问题本质，阻碍精准恢复和监控。
- 按异常语义分层捕获：先catch更具体的子类（如SQLException），再考虑父类（如RuntimeException）
- 对不同异常采取不同策略：连接超时可重试，数据校验失败应立即反馈用户，系统级错误需告警并降级
- 日志记录时保留原始异常链（e.printStackTrace()不够，要用logger.error("msg", e)）
