Java异常处理需按类型分层捕获、从具体到宽泛；检查型异常须处理或声明，非检查型可不处理；finally应判空关闭资源，优先用try-with-resources；自定义异常应有明确用途且避免过度包装。
Java中try-catch的基本写法与执行逻辑
Java异常处理的核心是try-catch结构，它不是“可选语法糖”，而是控制流的一部分：一旦throw抛出异常，当前方法栈帧立即中断，JVM沿调用栈向上查找匹配的catch块。没被捕获就终止线程（主线程即程序退出）。
常见错误是把所有逻辑塞进一个try块，再用多个catch兜底——这掩盖了异常的真实位置和类型。应按具体异常分类捕获，例如：
try {
int result = 10 / Integer.parseInt(args[0]);
} catch (NumberFormatException e) {
System.err.println("参数不是有效数字");
} catch (ArrayIndexOutOfBoundsException e) {
System.err.println("缺少命令行参数");
} catch (ArithmeticException e) {
System.err.println("除零错误");
}
-
catch块顺序必须从具体到宽泛，否则编译报错（如Exception写在NullPointerException前面） - 不要忽略
catch里的e.printStackTrace()——它默认输出到System.err，生产环境应记录到日志系统 - 如果只是想“吞掉”异常（极少数场景），至少加注释说明理由，避免后续排查时一头雾水
何时必须用try-catch，何时该用throws声明
Java强制区分检查型异常（checked exception）和非检查型异常（unchecked exception）。前者继承自Exception但不继承RuntimeException，比如IOException、SQLException；后者如NullPointerException、ArrayIndexOutOfBoundsException，编译器不强制处理。
关键判断点：你是否能为这个异常提供有意义的恢复动作？
立即学习“Java免费学习笔记（深入）”；
- 能——在当前方法用
try-catch处理（例如文件不存在时创建默认配置） - 不能——用
throws抛给上层，让更了解业务上下文的调用方决定（例如数据库连接失败，DAO层无法自行重试，应交由Service层统一处理） - 绝对不要在
main方法里throws Exception然后不管——这等于放弃处理
finally块的真实作用与常见误用
finally块保证执行，无论try是否抛异常、catch是否命中、甚至try里有return语句。但它不是“万能收尾工具”。
典型误用是把资源释放逻辑全丢进finally却不判空：
FileInputStream fis = null;
try {
fis = new FileInputStream("data.txt");
// ...读取操作
} finally {
fis.close(); // NullPointerException风险！fis可能根本没初始化成功
}
- 正确做法：JDK 7+ 优先用
try-with-resources，自动关闭实现了AutoCloseable的资源 - 若需手动关闭，
finally中必须判空：if (fis != null) fis.close(); - 避免在
finally里写return或抛异常——它会覆盖try或catch中的返回值或异常，造成逻辑错乱
自定义异常的设计要点
不要为了“看起来专业”而随便建MyBusinessException。自定义异常只有在需要传递额外上下文、或触发特定恢复策略时才有价值。
- 继承
RuntimeException还是Exception？取决于是否希望调用方强制处理。业务校验失败（如余额不足）通常用运行时异常；外部依赖失败（如HTTP调用超时）建议用检查型异常 - 构造函数至少提供
String message和Throwable cause两个版本，方便链式异常追踪 - 避免在异常类里放业务逻辑方法——异常对象只应承载错误信息，不是工具类
- 消息字符串别硬编码，尤其涉及用户可见提示时，应走i18n资源包
最常被忽略的一点：异常堆栈里真正有用的是“最早抛出的位置”，而不是层层包装后的最后一层。过度嵌套new MyException("xxx", e)反而模糊了根因。
