Java异常处理关键在正确使用：checked异常需显式处理，unchecked异常反映逻辑错误；应避免空catch、误用throws、finally抛异常，善用try-with-resources和分层异常转换。
Java异常处理机制不是“要不要用”的问题，而是“怎么用对”的问题。用错 try-catch 不仅掩盖真实问题，还可能引发资源泄漏、逻辑跳转失控或吞掉关键错误信号。
什么是 checked 异常和 unchecked 异常
Java 把异常分成两类：编译器强制你处理的 Exception 及其子类（除 RuntimeException），叫 checked 异常；另一类是 RuntimeException 及其子类，比如 NullPointerException、ArrayIndexOutOfBoundsException，属于 unchecked 异常，编译器不强制捕获或声明。
关键区别在于语义：checked 异常代表“预期外但可恢复的外部问题”，比如 IOException（文件读写失败）、SQLException（数据库连接中断）；unchecked 异常则多源于程序逻辑缺陷，比如空指针、数组越界、类型强转失败。
- 不要把
RuntimeException包进throws声明——它没意义，编译器也不检查 - 别为了过编译而写空
catch块，比如只写{}，这等于主动丢弃错误上下文 - 自定义业务异常建议继承
Exception（需显式处理）或RuntimeException（更轻量，适合非法参数、状态冲突等内部校验失败）
try-with-resources 为什么必须用，以及怎么用对
手动调用 close() 容易遗漏，尤其在 catch 或 finally 中抛出新异常时，旧异常会被吞掉。Java 7 引入的 try-with-resources 自动关闭实现了 AutoCloseable 的资源，且能保留原始异常（通过 suppressed 机制）。
立即学习“Java免费学习笔记（深入）”；
常见误用：
系统简介：冰兔BToo网店系统采用高端技术架构，具备超强负载能力，极速数据处理能力、高效灵活、安全稳定；模板设计制作简单、灵活、多元；系统功能十分全面，商品、会员、订单管理功能异常丰富。秒杀、团购、优惠、现金、卡券、打折等促销模式十分全面；更为人性化的商品订单管理，融合了多种控制和独特地管理机制；两大模块无限级别的会员管理系统结合积分机制、实现有效的推广获得更多的盈利！本次更新说明：1. 增加了新
- 把非
AutoCloseable对象（如普通 POJO）放进资源声明里，编译直接报错 - 在
try块内重新赋值资源变量，导致实际关闭的是旧对象或 null - 多个资源用分号隔开时，关闭顺序与声明顺序相反——后声明的先关闭，这点影响资源依赖关系（比如先关连接再关语句会出错）
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedInputStream bis = new BufferedInputStream(fis)) {
// 使用 bis 读取
} catch (IOException e) {
// e 中包含所有被抑制的 close 异常（如有）
}
catch 块的顺序和重抛策略
catch 块必须从具体到宽泛排列，否则编译报错。比如不能把 Exception 放在 IOException 前面，因为前者已覆盖后者。
重抛异常时注意三点：
- 用
throw e;是原样重抛，堆栈不变；用throw new RuntimeException(e);会丢失原始堆栈，除非显式传入e作为 cause - 在
catch里记录日志后想继续传播，别漏掉throw;，否则异常静默消失 - 不要在
finally里抛异常——它会覆盖try或catch中已抛出的异常
try {
doSomething();
} catch (FileNotFoundException e) {
log.warn("配置文件缺失，使用默认值", e);
useDefaultConfig();
} catch (IOException e) {
throw new UncheckedIOException(e); // 包装为 unchecked，避免上层被迫处理
}
log.error() 和 throw 新异常哪个更合适
取决于调用方能否/需要做差异化处理。如果上层有明确的降级路径（比如查缓存失败就返回兜底数据），应该抛出带业务语义的异常（如 ServiceUnavailableException），让调用方决定重试、降级还是告警；如果只是中间层日志归档，又无法改变流程，那就只记录 log.error("xxx failed", e) 并按需抛出包装异常。
容易被忽略的细节：
- Log 框架如 SLF4J 的
log.error(String, Throwable)方法必须传入异常对象，否则堆栈信息丢失 - 不要在
catch里只打印e.getMessage()，它通常为空或无意义（比如NullPointerException） - 同一异常被多次包装（
new BizException(new ServiceException(new IOException()))）会让调试链路变长，应控制包装层级
异常处理最难的部分不是语法，而是判断“这个错误该由谁响应、以什么方式响应”。一个 SQLException 在 DAO 层该转成数据访问异常，在 service 层可能要转成业务规则异常，在 controller 层也许该映射为 HTTP 500 或 409。每层的转换边界一旦模糊，就会出现异常被反复捕获又反复抛出，或者关键上下文在传递中丢失。
