try-catch必须配对使用，孤立try块编译失败；多catch需子类在前父类在后；try-with-resources仅支持AutoCloseable资源；禁用空catch，避免吞异常。

try-catch 块必须配对使用，不能只有 try 没有 catch 或 finally

Java 编译器会直接拒绝编译孤立的 try 块。哪怕你只想用 try 做资源初始化，也必须跟上至少一个 catch 或 finally。

• try 后面不能直接跟 if、for 或普通语句
• 常见错误写法：

  try {
      doSomething();
  }
  System.out.println("after"); // ❌ 编译报错：'try' without 'catch', 'finally' or resource declarations

• 正确写法是补上空 catch（不推荐）或带逻辑的 catch，或者用 finally 保证执行

捕获异常时，子类异常必须放在父类前面

多个 catch 块按顺序匹配，JVM 从上到下扫描。如果把 Exception 放在 IOException 前面，后者永远无法被捕获 —— 因为 IOException 是 Exception 的子类，已被前者“吃掉”。

• 编译器会报错：exception IOException has already been caught
• 正确顺序示例：

  try {
      readFile();
  } catch (FileNotFoundException e) {
      // 具体异常优先
      System.err.println("File not found: " + e.getMessage());
  } catch (IOException e) {
      // 更宽泛的 IO 异常放后面
      System.err.println("IO error: " + e.getMessage());
  } catch (Exception e) {
      // 最后兜底，但应尽量避免泛 catch
      System.err.println("Unexpected error: " + e.getClass().getSimpleName());
  }

• 注意：RuntimeException 及其子类（如 NullPointerException）属于 unchecked 异常，不强制捕获，但一旦出现在靠前的 catch 中，也会阻断后续更具体的异常匹配

try-with-resources 自动关闭资源，但仅限实现 AutoCloseable 的对象

不是所有“需要关闭”的对象都支持 try-with-resources。比如老式 java.sql.Connection（JDBC 4.0+ 才实现 AutoCloseable），或自定义流未显式实现该接口，就会编译失败。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 错误现象：cannot be auto-closed; it does not implement java.lang.AutoCloseable
• 必须确保资源类型声明在 try ( ... ) 小括号内，且构造/获取过程不抛出未处理异常
• 示例（正确）：

  try (FileInputStream fis = new FileInputStream("data.txt");
       BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
      String line = reader.readLine();
  } catch (IOException e) {
      e.printStackTrace();
  }

• 注意：多个资源用分号分隔；每个资源都会按声明逆序关闭（后声明的先关），且关闭异常会被抑制（suppressed），需调用 e.getSuppressed() 查看

不要吞掉异常（empty catch）或只打印堆栈却不处理

空 catch 块是最常见的隐患之一：异常发生后程序看似继续运行，但状态已损坏，后续逻辑可能出错，且难以定位源头。

立即学习“Java免费学习笔记（深入）”；

• 反模式写法：

  try {
      riskyOperation();
  } catch (Exception e) {
      // ❌ 什么也不做，或只写 e.printStackTrace()
  }

• 真实项目中应至少做到：
  • 记录日志（用 SLF4J / Log4j，而非 System.err）
  • 根据业务决定是否重试、降级、返回默认值或向上抛出
  • 若明确知道某异常可忽略（如 InterruptedException 在非中断敏感场景），也要加注释说明理由
• 特别警惕 catch (Throwable t) —— 它会捕获 Error（如 OutOfMemoryError），这类错误通常不应被应用层捕获或“恢复”

异常处理的关键不在语法多复杂，而在清楚每条 catch 覆盖了什么、没覆盖什么，以及被压制的关闭异常是否真无关紧要。