Java异常处理面试重在展现设计理解与工程判断：受检异常强制应对外部不确定性，运行时异常需预防而非捕获，Error不应被处理；finally非绝对执行，推荐try-with-resources；自定义异常要语义清晰、继承合理、支持上下文传递。
Java异常处理能力提升类面试题，核心不是背定义，而是展现你对异常机制的理解深度、实际判断力和工程意识。回答时紧扣“为什么这么设计”“什么场景该怎么做”“容易踩哪些坑”，比罗列概念更有说服力。
明确异常分类的底层逻辑
不要只说“Exception分运行时和受检”，要讲清设计意图：
- 受检异常（如 IOException、SQLException）是 Java 强制你正视外部不确定性——文件可能被删、网络可能断、数据库可能不可用。不处理就编译失败，倒逼你在调用点做决策：是立即恢复（重试/降级），还是向上声明让调用方兜底。
- 运行时异常（如 NullPointerException、IllegalArgumentException）代表程序内部逻辑缺陷。编译器不强制捕获，是因为它本不该发生；出现说明代码有漏洞，比如没校验入参、没判空、数组长度算错。重点应是预防，而不是 catch 住吞掉。
- Error（如 OutOfMemoryError）是 JVM 自身崩溃信号，不是你的代码能修复的。捕获它通常没有意义，反而掩盖真正问题。面试中若被问到“能不能 catch Error”，答“技术上可以，但工程上不推荐”更显专业。
讲清楚 try-catch-finally 的真实行为边界
很多候选人只记得“finally 总会执行”，但忽略关键例外：
- finally 在 try 或 catch 中遇到 System.exit()、JVM 崩溃、线程被 kill 时，不会执行；
- 如果 finally 里抛出新异常，它会覆盖 try/catch 中已有的异常（除非 catch 里显式 throw）；
- JDK 7+ 推荐用 try-with-resources 替代手动 close，它本质是在字节码层面确保资源关闭，比 finally 更可靠，也更简洁。
展示异常处理的工程判断力
面试官常给一个模糊场景，比如：“用户上传文件失败，该怎么处理？” 此时要分层回应：
立即学习“Java免费学习笔记（深入）”；
- 定位层级：是 IOException（磁盘满/权限不足）？还是 IllegalArgumentException（文件名含非法字符）？还是自定义的 BusinessValidationException（业务规则不通过）？不同层级对应不同策略。
- 响应方式：底层 IO 异常适合记录 warn 日志 + 返回友好提示（如“服务器暂时无法处理，请稍后重试”）；参数异常应快速失败，返回 400 + 明确字段错误；业务异常可触发补偿流程或通知运营。
- 避免反模式：不写 catch (Exception e) { } 空吞异常；不把 SQLException 包装成 RuntimeException 就为了不声明 throws，除非你确定所有调用方都准备好处理它。
能说出自定义异常的设计要点
这不是炫技，而是体现你对 API 可维护性的理解：
- 继承 RuntimeException 表示调用方无需强制处理，适合业务流程中断类异常（如 InsufficientBalanceException）；
- 继承 Exception 表示必须声明或捕获，适合集成外部系统失败等需显式兜底的场景；
- 构造函数建议提供 String message 和 Throwable cause 两个重载，方便链式传递上下文；
- 异常类名本身就要表达语义，比如 PaymentTimeoutException 比 ServiceException 更清晰。
