try-catch 是捕获、响应和控制异常流的机制，需精准捕获特定类型、提取异常信息（如消息、原因链、堆栈）、结合 try-with-resources 保障资源释放，并按业务语义设计差异化响应策略。
try-catch 不是用来“解析”错误的工具，而是用来**捕获、响应和控制异常流**的机制。所谓“解析底层错误”，实际是指在捕获异常后，通过合理提取和利用异常对象的信息（如类型、消息、堆栈、原因链），定位问题根源并做出恰当处理。关键不在“解析”本身，而在捕获得准、读取得清、响应得当。
精准捕获特定异常类型
避免用 catch (Exception e) 一锅端。宽泛捕获会掩盖真实问题，也失去区分处理的机会。
- 明确知道哪段代码可能出什么错：比如文件操作优先捕获 FileNotFoundException 和 IOException
- 子类异常必须放在父类之前，否则编译失败。例如 SQLException 要在 Exception 前面
- Java 7+ 支持多异常合并写法：catch (IOException | SQLException e)，适合处理语义相近、响应逻辑一致的异常
从异常对象中提取有效信息
捕获到异常后，别只打印 e.printStackTrace() 就完事。真正有用的信息藏在异常对象的方法里：
- e.getMessage()：返回简短错误描述（如 "No such file or directory"），适合给用户或日志摘要
- e.getCause()：获取原始异常（比如 SQL 异常包装了 JDBC 驱动异常），层层调用可追溯根本原因
- e.getStackTrace()：返回堆栈数组，可用于结构化日志或过滤关键调用帧
- e.getClass().getSimpleName()：快速判断异常种类，便于做类型分支处理（如自动重试 vs 终止流程）
结合 finally 或 try-with-resources 确保上下文完整
很多“底层错误”其实源于资源未释放导致的连锁反应（如文件句柄耗尽、连接泄漏）。仅捕获异常不够，还要保障环境干净：
- 旧方式：在 finally 中手动判空关闭资源，但嵌套 try-catch 易出错
- 推荐方式：使用 try-with-resources（要求资源实现 AutoCloseable），JVM 自动确保关闭，且关闭异常不会覆盖主异常
- 示例：try (FileInputStream fis = new FileInputStream("data.txt")) { ... } —— 即使读取时抛异常，fis 仍会被关闭
按场景设计响应策略，而非仅记录
捕获异常后的动作，应由业务语义决定，不是所有异常都该吞掉或重抛：
- 用户输入错误（如 NumberFormatException）→ 返回友好提示，不记 error 日志
- 外部依赖失败（如网络超时、DB 连接中断）→ 记录 warn 日志，考虑降级或重试
- 不可恢复状态（如配置缺失、核心类加载失败）→ 记录 error 日志，主动终止模块或服务
- 需上层决策的异常（如业务规则校验失败）→ 封装为自定义异常向上抛，不在此处处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
