Java异常处理应优先用try-with-resources自动管理资源，精简catch块只捕获可处理异常，合理取舍finally以提升简洁性与健壮性。
Java里用try-catch-finally处理异常，关键不是堆砌代码，而是让错误可控、资源不泄漏、逻辑不臃肿。真正影响简洁性的，往往不是语法本身，而是写法选择和资源管理策略。
try-catch-finally 本身不复杂，但容易写冗长
传统写法常把资源声明放在try外、判空关流塞进finally，导致代码重复、缩进深、可读性下降。比如手动关闭FileReader时，要反复检查是否为null；多个资源嵌套时，嵌套层级迅速变深。
- 资源声明与初始化混在业务逻辑里，职责不清
- finally中大量判空+try-catch嵌套，掩盖主干逻辑
- catch块过多或顺序错乱（如父类异常写在子类前），反而增加维护成本
优先用 try-with-resources 替代手写 finally
Java 7 引入的 try-with-resources 是提升简洁性和安全性的首选。只要资源实现 AutoCloseable 接口（如 FileInputStream、BufferedReader、Connection），就能自动关闭，无需手动判空或写 finally。
- 一行声明资源，自动关闭，代码行数减少 40% 以上
- 即使 try 中抛出异常，close() 仍会被调用，且异常会正确叠加（Suppressed Exception）
- 多个资源可用分号分隔，自动按逆序关闭，避免资源依赖问题
catch 块要精简，不是越多越好
捕获异常的目标是「有意义地响应」，不是「把所有可能都列出来」。过度细分 catch 会让代码膨胀，却未必提升健壮性。
立即学习“Java免费学习笔记（深入）”；
- 只捕获你真能处理的异常类型（如 FileNotFoundException 可重试或提示用户）
- 对无法恢复的运行时异常（如 NullPointerException），通常不该 catch，而应修复源头
- 兜底 catch (Exception e) 要谨慎：若只是 e.printStackTrace()，等于“吞异常”，反而掩盖问题
finally 不是万能收尾区，该省则省
finally 的价值在于「必须执行」，但不是所有清理逻辑都得放这儿。现代写法中，很多场景根本不需要显式 finally：
- 资源已用 try-with-resources 管理 → 删除冗余 finally
- 纯计算逻辑无外部资源 → 通常连 finally 都不需要
- 日志记录、指标上报等非关键操作，可放在 catch 后直接执行，不必强塞 finally
简洁不是删代码，而是让每行代码承担明确责任。try-with-resources 减少样板，精准 catch 避免干扰，合理取舍 finally，三者配合才能写出既健壮又清爽的异常处理逻辑。
