Java中必须用try-catch处理受检异常（如IOException、InterruptedException），而非运行时异常；catch块须记录日志、转换异常或局部恢复，禁用空catch和e.printStackTrace()；多异常捕获需子类优先；资源操作应使用try-with-resources。
Java 中 try-catch 不是用来“吞掉”异常的，而是为了在可控范围内响应错误、恢复流程或提供有意义的反馈。盲目包裹所有代码进 try-catch 反而会掩盖问题。
什么时候必须用 try-catch？
只有当调用的代码明确声明抛出 Exception（非 RuntimeException）子类时，编译器才强制你处理——比如 FileInputStream 构造、Thread.sleep()、ObjectOutputStream.writeObject()。这类异常叫“受检异常（checked exception）”，不处理就编译不过。
常见场景包括：
- 文件读写：
IOException - 网络请求：
UnknownHostException、SocketTimeoutException - 反射操作：
ClassNotFoundException、IllegalAccessException - 日期解析：
ParseException
而 NullPointerException、ArrayIndexOutOfBoundsException 这类运行时异常（unchecked），编译器不管，但你不该靠 try-catch 来预防——应该提前校验参数或修复逻辑漏洞。
立即学习“Java免费学习笔记（深入）”；
catch 块里不能只写 e.printStackTrace()
这行代码只把堆栈输出到标准错误流，在生产环境几乎无用：日志没分级、没上下文、不可检索、还可能被重定向丢弃。
正确做法是：
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
- 用日志框架（如 SLF4J）记录，带上业务上下文：
log.error("Failed to parse config file: {}", filename, e) - 必要时转换异常类型，向上抛出更语义化的异常：
throw new ConfigLoadException("Invalid JSON in " + path, e) - 若能局部恢复（如默认值兜底），才做具体处理：
return DEFAULT_TIMEOUT;
特别注意：不要捕获 Exception 或 Throwable 后什么都不做（即空 catch 块），这是最危险的习惯——OutOfMemoryError 都可能被静默吞掉。
多个 catch 的顺序和资源自动关闭（try-with-resources）
如果要捕获多个异常类型，子类必须写在父类前面，否则编译报错：Catch clause for 'IOException' is unreachable。例如：
try {
// ...
} catch (FileNotFoundException e) { // ✅ 子类优先
log.warn("Config not found, using defaults", e);
} catch (IOException e) { // ✅ 父类放后
throw new ServiceException("IO failed", e);
}
涉及资源（文件、连接、流等）时，别手动写 finally 关闭——容易漏、易 NPE。直接用 try-with-resources：
try (FileInputStream fis = new FileInputStream("data.bin");
DataInputStream dis = new DataInputStream(fis)) {
return dis.readInt();
} catch (IOException e) { // 自动关闭 fis 和 dis，即使 readInt() 抛异常
throw new DataReadException(e);
}
注意：所有资源类必须实现 AutoCloseable 接口，且构造失败时不会触发 close（安全）。
finally 块不是万能收尾工具
finally 会在 try/catch 执行完后无条件执行，但它不解决所有清理问题：
- 如果 try 块中调用了
System.exit(0)，finally不会执行 - 如果 JVM 崩溃或线程被强制中断（
Thread.stop()），finally失效 -
finally里再抛异常会覆盖原异常（除非你显式处理）
所以现代 Java 更推荐：资源用 try-with-resources，状态清理（如解锁、重置标志位）放在业务方法末尾或使用 Cleaner / PhantomReference 做兜底，而不是依赖 finally。
真正难处理的是跨线程异常、异步回调里的异常、以及未捕获的 Thread.UncaughtExceptionHandler 场景——这些已超出单个 try-catch 范畴，需要统一错误传播机制设计。
