精准捕获、合理处理、安全收尾是try-catch-finally的核心：需按异常类型分层捕获、记录完整堆栈、用try-with-resources或判空关闭资源、规范处理受检异常，避免空catch和finally中return。
写 try-catch-finally 不是加个壳就完事，关键在“精准捕获、合理处理、安全收尾”。很多程序看似能跑，一出错就哑火、难排查、资源泄漏，根源常藏在这几个误区里。
别用 Exception 一锅端
catch (Exception e) 看似省事，实则掩盖问题本质。它会把 NullPointerException、IOException、IllegalArgumentException 全部吞进同一个分支，日志里只剩“发生异常”，根本分不清是代码逻辑错、文件没找到，还是网络断了。
- 按实际风险类型逐个 catch：文件操作优先捕 FileNotFoundException 和 IOException；数据库操作捕 SQLException；数值转换捕 NumberFormatException
- 子类异常必须放在父类前面，否则编译不通过——比如 IOException 要写在 Exception 之前
- 真要兜底，也建议单独加一个 catch (Exception e) 放最后，仅用于记录未知异常，不能替代具体处理
catch 里不能只打一句“出错了”
空 catch 块（catch (Exception e) {}）或只输出模糊提示，等于主动销毁线索。异常堆栈信息（e.printStackTrace() 或日志框架的 error(e)）才是定位问题的核心依据。
- 至少记录异常类型、消息和完整堆栈，例如：log.error("用户登录失败，用户名: {}", username, e)
- 避免在生产环境用 System.out.println 打印异常，应统一走日志框架（如 SLF4J + Logback）
- 对可预期的业务异常（如密码错误、余额不足），可转为友好提示返回，而非抛出或静默忽略
finally 不等于“随便写点清理代码”
finally 的本意是确保资源释放，但写法不当反而引发新异常，比如未判空就调 close()，或在 finally 里 return 覆盖原返回值。
立即学习“Java免费学习笔记（深入）”；
- 变量声明要前置并初始化为 null，关闭前判空：if (reader != null) try { reader.close(); } catch (IOException ignored) {}
- 强烈推荐 Java 7+ 的 try-with-resources：自动管理 AutoCloseable 资源，无需手写 finally（如 try (FileReader r = new FileReader("x.txt")) { ... }）
- 绝对不在 finally 中写 return 或 throw ——它会强行中断 try/catch 的返回逻辑，导致结果不可预测
别忘了受检异常的强制约束
IOException、SQLException 这类受检异常，编译器会强制你处理。跳过它们（比如删掉 throws 声明又不 catch），代码根本编译不过，不是运行时才暴露的问题。
- 要么在当前方法用 try-catch 处理
- 要么用 throws 向上抛出，由调用方负责——但需明确文档说明，避免责任模糊
- 不要为了编译通过而简单 throw new RuntimeException(e)，这会把本该显式处理的问题转成运行时隐患
