Java异常处理是程序健壮性基础设施，核心为Throwable及其子类Error（JVM级不可恢复错误）和Exception（需处理的异常，分受检与非受检两类）；try-catch-finally需注意捕获顺序、finally执行条件及资源管理优先用try-with-resources；throw用于主动抛出异常，throws仅声明受检异常；NullPointerException因编译器不检查而高发，需结合Optional、@NonNull与契约意识防控。
Java中的异常处理机制，本质是「程序出错时不让它直接崩溃，而是交由开发者可控地响应」——它不是补救措施，而是程序健壮性的基础设施。
什么是 Throwable？所有异常的起点
Java中一切可被抛出的错误或异常，都必须是 Throwable 的子类。它不是用来被直接实例化的，而是作为整个异常体系的根。你写代码时永远接触不到 Throwable 本身，但会频繁看到它的两个直系子类：Error 和 Exception。
-
Error：JVM 级别问题，比如OutOfMemoryError、StackOverflowError。这类错误程序无法恢复，也不该用try-catch捕获 -
Exception：才是你要处理的“异常”，再细分为两类： - 受检异常（
Checked Exception）：如IOException、SQLException。编译器强制你处理——要么try-catch，要么在方法签名加throws - 非受检异常（
Unchecked Exception）：即RuntimeException及其子类，如NullPointerException、ArrayIndexOutOfBoundsException。编译器不管，但恰恰是编码疏漏最常暴露的地方
try-catch-finally 怎么写才不踩坑
这是最常用、也最容易误用的结构。关键不在语法，而在语义意图是否清晰。
- 多个
catch块必须按「子类在前、父类在后」排列，否则子类永远捕获不到。例如FileNotFoundException必须写在IOException之前 -
finally一定会执行——除非 JVM 直接退出（如System.exit()）或线程被中断。但它不是“资源清理唯一方案”：JDK 7+ 推荐用try-with-resources自动关闭AutoCloseable资源 - 不要在
catch里只写e.printStackTrace()就完事。生产环境应记录日志（如 SLF4J），必要时包装异常再抛出，保留原始堆栈
try (FileInputStream fis = new FileInputStream("data.txt")) {
// 自动关闭，无需 finally
} catch (FileNotFoundException e) {
logger.error("文件未找到: {}", "data.txt", e);
throw new BusinessException("读取配置失败", e);
}
什么时候该用 throw，什么时候用 throws
throw 是动作（抛出一个异常对象），throws 是声明（告诉调用者“我可能抛这个”）。二者混用是新手高频错误。
立即学习“Java免费学习笔记（深入）”；
- 用
throw：当检测到非法状态时主动中断流程，比如参数为null时抛IllegalArgumentException - 用
throws：仅用于方法签名，且只对受检异常有意义。对RuntimeException加throws是无效冗余（编译器不拦，IDE 可能警告） - 慎用
throws Exception：它掩盖了真实异常类型，让调用方无法针对性处理，属于设计倒退
为什么空指针异常（NullPointerException）最难防又最该防
它不属于受检异常，编译器完全不提醒，但却是线上故障头号原因。根源往往不是“没判空”，而是“不知道哪里可能为 null”。
- 返回值：调用第三方 SDK 或数据库查询结果，未检查是否为
null就直接调用.length()或.getXXX() - 集合操作：
Map.get(key)返回null是合法行为，但后续未做空判断就强转或解包 - 现代解法：用
Optional<T>显式表达“可能为空”，或用 Lombok 的@NonNull+ 编译期检查
真正难的不是写 if (obj != null)，而是建立「谁负责保证非空」的契约意识——接口文档、单元测试、静态分析工具，缺一不可。
