java异常处理核心是合理使用try-catch-finally：try仅包裹真正可能抛异常的i/o或解析操作；catch需具体捕获子类异常并妥善处理；finally专注资源清理，优先用try-with-resources，禁用return或抛异常。
Java异常处理的核心在于合理使用try-catch-finally结构，既要捕获并处理可恢复的异常，也要确保资源释放和逻辑完整性，而不是简单“吞掉”异常或盲目抛出。
明确try块的边界：只包裹可能抛异常且需要统一处理的代码
try块不是万能包装纸。它应仅包含真正可能抛出受检异常（如IOException）或运行时异常（如NullPointerException），且这些异常后续有对应处理逻辑的代码。避免把无关逻辑（如纯计算、日志打印）塞进try，否则会干扰异常定位，也增加不必要的性能开销。
- ✅ 推荐：打开文件、读取流、解析JSON等I/O或转换操作放
try - ❌ 避免：在
try里先做参数校验、再调用外部方法——校验失败应直接返回或抛业务异常，不依赖catch
catch要具体，优先捕获子类异常，慎用Exception或Throwable
捕获太宽泛的异常类型（如catch (Exception e)）容易掩盖真实问题，导致调试困难，甚至让本该中断流程的严重错误被静默忽略。
- 按异常语义分层捕获：例如先
catch (FileNotFoundException e)提示“文件不存在”，再catch (SecurityException e)提示“权限不足”，最后才考虑兜底处理 - 不要用
catch (Throwable t)——它会捕获Error（如OutOfMemoryError），这类错误通常不可恢复，强行捕获反而阻碍JVM正常终止 - 捕获后务必处理：记录日志（含堆栈）、向用户反馈友好提示、或执行补偿动作；避免空
catch块
finally不是“必须写”，而是“需要清理时才用”
finally的核心价值是保障关键清理逻辑（如关闭流、释放锁、回滚事务）一定执行，无论try是否异常、catch是否触发、甚至遇到return或System.exit()（后者除外）。
- 资源管理优先用try-with-resources（JDK 7+）：对实现了
AutoCloseable的类（如FileInputStream、Connection），用try (Resource r = new X()) { ... }自动关闭，比手动finally更简洁安全 - 手动
finally中关闭资源需判空且嵌套try-catch：防止关闭过程本身抛异常覆盖原异常（如close()抛IOException） - 避免在
finally里写return或抛异常：它会覆盖try或catch中的返回值或异常，造成逻辑错乱
return与异常共存时的执行顺序要心里有数
当try或catch中有return，finally仍会执行——但它不能改变已确定的返回值（基本类型/不可变对象），也不能阻止异常传播（除非finally自己抛异常）。
-
try中return 1;→ 记录返回值1 → 执行finally→ 返回1 -
try中return obj;（obj为引用）→ 记录obj引用 →finally中修改obj.field = 2;→ 返回的obj字段已被改 -
finally中return 99;→ 会覆盖try的返回值，且隐藏原异常 —— 这是反模式，禁止使用
异常处理不是代码补丁，而是设计的一部分。写try-catch-finally前，先想清楚：这个异常是否真的该在这里处理？有没有更早预防的可能？资源是否已用现代方式托管？答案清晰了，代码自然就稳了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
