应减少try块代码量，仅包裹io、解析、类型转换等高风险操作；用if提前校验替代异常兜底；拆分方法使每个try职责单一；配合try-with-resources自动管理资源。
减少 try 块包裹的代码行数，本质是让异常边界更清晰、主流程更聚焦。大段逻辑塞进一个 try 中，不仅掩盖了真正可能出错的位置，还导致 catch 处理难以精准对应，后期修改时容易误伤或遗漏异常路径。
只包裹真正可能抛异常的操作
try 块应仅覆盖调用外部资源、解析输入、转换类型等明确有异常风险的语句，而非整个业务方法。
- ✅ 好做法：把
FileInputStream构造、readLine()、Integer.parseInt()这类高风险操作单独包裹，其他校验、计算、赋值等稳定逻辑移出 try - ❌ 避免：把从参数校验、数据库查询、结果组装全包进一个 try —— 一旦
NullPointerException在中间抛出，你无法区分是数据为空还是 IO 失败
用提前校验替代异常兜底
对可预判的错误，优先用 if 判断拦截，而不是依赖 catch 捕获运行时异常。
OpenJDK 24 Windows x64
下载
OpenJDK 24 Windows x64 官方参考实现（24+36），适合 Windows 环境进行 Java 开发、编译、运行和版本兼容性验证。
- 比如传入 null 或空字符串时，直接
if (str == null || str.trim().isEmpty()) throw new IllegalArgumentException("参数不能为空") - 这样既避免了
NumberFormatException或NullPointerException被混在 catch 块里处理，又让错误语义更明确、调用方更容易理解失败原因
拆分方法，让每个 try 有唯一职责
把长方法按功能切分为多个小方法，每个只负责一类操作，并在各自内部处理对应异常。
- 例如将“读配置→解析JSON→校验字段→存入缓存”拆成
loadConfig()、parseJson()、validateConfig()等 - 每个方法内部的 try 只管自己那一步的异常，上层方法只需关注是否继续执行，无需处理底层细节
- 这样修改某一步逻辑（如换 JSON 库）时，影响范围可控，测试也只需覆盖该方法
配合 try-with-resources 控制资源边界
涉及流、连接、通道等资源时，用 try-with-resources 替代手动 close，自然压缩 try 块体积。
- 原来要写 open → use → close 三段，现在声明即管理，use 区域只剩核心逻辑
- 资源生命周期与异常处理解耦，不会因忘记 close 导致后续异常掩盖真实问题
- 代码行数减少的同时，异常堆栈更干净，定位问题更快
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
