Java异常处理最佳实践是理解异常设计意图并权衡可读性、健壮性与维护性：区分checked（需显式处理）与unchecked（编程错误）异常；自定义业务异常建议继承RuntimeException；捕获要具体、处理要明确；善用try-with-resources防资源泄漏；异常信息须带上下文且日志分级。
Java 异常处理最佳实践不是死记硬背语法，而是理解“什么时候该抛、该捕、该忽略，以及怎么让异常真正帮上忙”。面试官想看的，是你对异常设计意图的把握，和在真实项目中权衡可读性、健壮性与维护性的能力。
区分 checked 与 unchecked 异常，按语义选型
Checked 异常（如 IOException、SQLException）代表调用方**有能力且应该处理**的可恢复问题；Unchecked（RuntimeException 及其子类）代表编程错误或不可控的系统问题（如空指针、数组越界、并发修改）。不要为了“编译通过”而盲目 catch 后吞掉 checked 异常，也不要把本该由调用方决策的业务异常（比如“余额不足”）定义成 RuntimeException。
- 自定义业务异常建议继承 RuntimeException（如 InsufficientBalanceException），避免强制上层冗余 try-catch
- 涉及外部资源（文件、网络、数据库）的操作，保留或包装原始 checked 异常，体现“可能失败”的契约
- 不要用 Exception 或 Throwable 做通用 catch——它会掩盖真正的错误类型和意图
捕获要具体，处理要明确
catch (Exception e) 是危险信号。它可能把 NullPointerException 和 IOException 一锅端，导致逻辑错乱或掩盖 bug。真正需要处理的，是某类异常对应的具体场景。
- 优先捕获最具体的异常类型，比如先 catch FileNotFoundException，再 catch IOException
- 每个 catch 块要有清晰目的：重试、降级、转换为业务语义、记录上下文后重新抛出（throw new XxxException("描述", e)）
- 避免空 catch 块（catch (Exception e) { }）——日志都不打，等于静默失败
善用 try-with-resources 和 finally 的边界责任
资源泄漏是常见隐患。JDK 7+ 的 try-with-resources 自动关闭实现了 AutoCloseable 的资源（如 FileInputStream、Connection），比手动写 finally 更安全简洁。
立即学习“Java免费学习笔记（深入）”；
- 所有需要显式关闭的资源，优先声明在 try 后的小括号里
- finally 适合放“无论如何都要执行”的清理逻辑（如解锁、重置状态），但别在里面 throw 新异常——会覆盖原异常
- 如果 try 和 finally 都抛异常，JVM 会压制 finally 中的异常，只抛 try 中的；若需暴露两者，用 addSuppressed() 显式关联
异常信息要带上下文，日志要分清级别
“Null pointer exception” 这类信息对排查毫无帮助。异常消息应说明“哪里出问题、为什么出问题、当时关键数据是什么”。
- 构造异常时传入有意义的 message，例如：new IllegalArgumentException("userId 不能为 null，当前值: " + userId)
- 记录日志时，error 级别用于真正需要干预的问题（如 DB 连接失败）；warn 用于可容忍的异常（如第三方接口超时降级）；debug/info 一般不记异常堆栈
- 敏感信息（密码、身份证号）绝不能出现在异常消息或日志中
