Java异常机制本质是将运行时错误封装为Throwable对象以实现可控处理；异常分Error（不可恢复）和Exception（需处理），后者又分受检与非受检；应按类型分层捕获、避免宽泛catch，用try-with-resources确保资源释放。
Java异常机制的本质，是把“程序出错了”这件事，变成一个可识别、可捕获、可传递的对象（Throwable子类实例），而不是让JVM直接崩溃退出。
什么是异常？不是语法错，也不是逻辑错
异常只发生在运行时——代码能编译通过、字节码能加载，但执行到某一行时，环境或逻辑不满足预期，JVM就创建一个异常对象并throw出去。比如：
-
NullPointerException：你调用str.length()，但str是null -
ArrayIndexOutOfBoundsException：数组只有3个元素，你却读arr[5] -
ArithmeticException：整数除零：10 / 0
这些都不是写错关键字或少了个分号，而是程序在真实运行中“踩了坑”。异常机制让你有机会在坑边拉住程序，而不是任它掉下去终止。
异常体系结构：三根柱子——Throwable、Error、Exception
所有异常都从Throwable出发，它有两个不可变的直系子类：
立即学习“Java免费学习笔记（深入）”；
-
Error：JVM自己扛不住的严重问题，如OutOfMemoryError（堆内存爆了）、StackOverflowError（递归太深栈溢出）。你不该catch它，也基本无法恢复——该调JVM参数，或改算法。 -
Exception：这才是你要管的。它再分两支：-
受检异常（Checked Exception）：编译器强制你处理，比如
IOException、SQLException。它们代表外部不确定性（文件可能被删、网络可能断），你得明确决定是try-catch消化掉，还是用throws甩给上层。 -
非受检异常（Unchecked Exception）：即
RuntimeException及其子类，如NullPointerException。编译器不管，但它们几乎全是代码缺陷——没判空、没校验参数、没防越界。最佳实践是**提前防御，而非事后捕获**。
-
受检异常（Checked Exception）：编译器强制你处理，比如
为什么不能随便catch (Exception e)？
这是新手最常踩的坑：用一个宽泛的catch (Exception e)包住所有异常，然后只打一句日志或什么也不做。后果很实际：
- 掩盖真正问题：
NullPointerException和SQLException混在一起处理，你根本分不清是代码写错了，还是数据库连不上。 - 丢失关键信息：
e.getMessage()可能只是"null"，而e.printStackTrace()才能看到哪一行、哪个方法、什么调用链出的问题。 - 吞掉受检异常语义：比如
FileNotFoundException本意是“这个配置文件必须存在”，你一把抓走还忽略，等于默认它可有可无，系统行为就不可靠了。
正确做法是：按具体类型分层捕获，优先捕获最具体的异常（如先catch (FileNotFoundException e)，再catch (IOException e)），并在catch块里做有意义的事——重试、降级、记录带上下文的日志、向用户返回友好提示。
finally和try-with-resources：资源清理别靠运气
打开文件、数据库连接、网络套接字后，如果中途抛异常，不关资源就会泄漏。过去靠finally手动关：
FileInputStream fis = null;
try {
fis = new FileInputStream("data.txt");
// 读取...
} finally {
if (fis != null) fis.close(); // 容易漏写、容易抛新异常
}
现在推荐try-with-resources（JDK 7+），只要资源实现AutoCloseable接口（所有标准IO类都实现了）：
try (FileInputStream fis = new FileInputStream("data.txt")) {
// 读取...
} // 自动调用 fis.close()，哪怕中间抛异常也保证执行
注意：try-with-resources声明的变量是隐式final的，且关闭顺序与声明顺序相反——这点在嵌套资源（如BufferedInputStream套FileInputStream）时很重要。
真正难的从来不是“怎么写try-catch”，而是判断“该不该捕”“该在哪一层捕”“捕到之后该不该继续往上抛”。异常设计本质是契约：方法签名里的throws是你对调用方的承诺，catch是你对错误的担责边界。越往业务层走，越要减少裸抛异常；越靠近基础设施（IO、DB、HTTP），越要精确暴露受检异常。
