Error是JVM级不可恢复的严重错误（如OutOfMemoryError），不应捕获；Exception分两类：运行时异常（如NullPointerException）属逻辑错误，应修复而非依赖catch；编译时异常（如IOException）是外部不确定性，编译器强制处理或声明。
Java异常处理面试题，核心不是背定义，而是看三点：异常怎么分、错误怎么抓、责任怎么划。
看异常分类是否清晰
面试官常问“Error和Exception区别”“运行时异常和编译时异常怎么区分”，本质是在检验你对Throwable体系的理解深度。关键不是记住名字，而是能说清：
- Error是系统级崩溃，比如OutOfMemoryError、StackOverflowError，程序无法恢复，也不该捕获
- RuntimeException是代码逻辑缺陷，如NullPointerException、ArrayIndexOutOfBoundsException，应通过修复代码避免，而非依赖catch
- Checked Exception是外部不确定性，如IOException、SQLException，编译器强制你面对它——要么处理，要么声明，不能视而不见
看异常处理是否合理
光会写try-catch不算过关。面试会盯住细节，比如：
- 多个catch的顺序是否正确（子类在前、父类在后）
- finally里有没有return（会覆盖try/catch中的返回值）
- 资源释放是否可靠（推荐用try-with-resources替代手动close）
- 是否用空catch吞掉异常（这是大忌，至少要log或重新抛出）
看异常责任是否明确
高级问题往往落在设计层面：
立即学习“Java免费学习笔记（深入）”；
- 方法该自己处理异常，还是用throws交给上层？——原则是“谁更清楚怎么应对，就由谁负责”
- 要不要自定义异常？——当业务语义需要统一错误码、可读提示或分类统计时，就该封装
- 捕获Exception再throw新异常时，有没有调用initCause保留原始堆栈？——这是诊断问题的关键线索
真正拉开差距的，不是能不能写出语法正确的try块，而是能否讲清楚每一行背后的权衡：为什么这里用checked，那里用unchecked；为什么这个异常该吞，那个必须透传；为什么finally不能替代try-with-resources。
