不是。java中仅检查型异常必须显式处理，非检查型异常（如runtimeexception）可选捕获；应优先捕获具体异常类型，catch块须按子类到父类顺序排列；资源实现autocloseable时应优先用try-with-resources；throw抛出异常实例，throws声明异常类型。
Java中try-catch必须捕获Exception吗？
不是。捕获范围取决于异常类型：检查型异常（Checked Exception）必须显式处理（要么try-catch，要么声明throws），而非检查型异常（RuntimeException及其子类）可选捕获。
常见误操作是用catch (Exception e)一锅端，掩盖了本该由调用方决策的错误语义。比如NullPointerException通常反映逻辑缺陷，不该被静默吞掉。
-
IOException、SQLException属于检查型异常，编译器强制你处理 -
IllegalArgumentException、ArrayIndexOutOfBoundsException属于非检查型，不捕获也能通过编译 - 优先捕获具体异常类型，如
catch (FileNotFoundException e)，而非笼统的Exception
多个catch块的顺序为什么不能乱？
Java按catch块从上到下的顺序匹配异常类型，且子类必须在父类之前——否则编译报错：error: exception XXX has already been caught。
例如IOException是Exception的子类，若把catch (Exception e)写在前面，后面所有具体异常分支都不可达。
立即学习“Java免费学习笔记（深入）”；
try {
readFile();
} catch (FileNotFoundException e) { // ✅ 具体异常放前
System.err.println("文件未找到：" + e.getMessage());
} catch (IOException e) { // ✅ 更宽泛但仍在具体之后
System.err.println("IO错误：" + e.getMessage());
} catch (Exception e) { // ❌ 放最后，兜底用
System.err.println("未知错误：" + e.getClass().getSimpleName());
}
什么时候该用try-with-resources而不是普通try-catch？
只要资源实现了AutoCloseable接口（如FileInputStream、Connection、Scanner），就该优先用try-with-resources——它能自动调用close()，避免因忘记关闭或finally中抛异常导致资源泄漏。
注意：资源声明必须在try括号内，且不能是null（否则会抛NullPointerException）。
- 普通
try-finally容易漏写close()，或在finally里没判空就调用close() -
try-with-resources中多个资源用分号隔开，关闭顺序与声明顺序相反 - 如果
close()本身抛异常，会被抑制（suppressed），可通过e.getSuppressed()获取
try (FileInputStream fis = new FileInputStream("data.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
String line = reader.readLine();
System.out.println(line);
} catch (IOException e) {
System.err.println("读取失败：" + e.getMessage());
}
throw和throws的区别到底在哪？
throw用于在方法体内**抛出一个异常实例**，是运行时动作；throws用于在方法签名后**声明可能抛出的异常类型**，是编译期契约。
混淆二者会导致编译失败或语义错误。比如在方法里写了throw new IOException()却不加throws IOException，编译器会报错（因为它是检查型异常）。
-
throw后面跟的是异常对象，如throw new IllegalArgumentException("id不能为空") -
throws后面跟的是异常类名，可多个，用逗号分隔，如public void save() throws IOException, SQLException - 自定义异常若继承
RuntimeException，则无需throws声明，但依然可用throw抛出
throw new XxxException("提示", cause)构造带原因的异常，而不是丢掉原始堆栈。否则排查问题时会丢失关键上下文。 
