java编译器仅强制处理受检异常（继承exception但非runtimeexception的子类），如filenotfoundexception；而runtimeexception及其子类（如nullpointerexception）编译时放行，运行时抛出。

看编译器会不会拦你——最准的现场判断法

Java 编译器只对受检异常（Checked Exception）强制要求处理：不 try-catch，也不在方法签名加 throws，就直接编译失败。而 RuntimeException 及其子类，比如 NullPointerException、IllegalArgumentException，编译器完全不管，写完就能过。

• FileNotFoundException → 编译报错：“Unhandled exception type FileNotFoundException” → 必须处理 → 受检异常
• s.toString()（s == null）→ 编译通过，运行时抛 NullPointerException → 运行时异常
• 查不准？按住 Ctrl（Windows）或 Cmd（macOS）点进异常类源码，看它是不是直接或间接继承自 RuntimeException；如果不是，且是 Exception 的子类，那就是受检的

别信名字：比如 UnsupportedEncodingException 听起来像“不支持”，但它其实是 IOException 的子类 → 受检异常。

文件/网络/数据库出问题，优先用受检异常

这类异常对应的是程序无法控制但可预期的外部状况，比如磁盘上文件被删了、远程服务暂时不可达、数据库连接池耗尽。它们不是 bug，而是环境现实。

• 用 IOException 或 SQLException 暴露风险，迫使调用方考虑“如果读不到怎么办？”“连不上库要不要重试或降级？”
• 不该一 catch 就吞掉：catch (IOException e) { } 是典型掩盖问题，比不处理还糟
• 更合理的做法是：向上声明 throws IOException，让业务层决定恢复策略（如返回默认值、走缓存、提示用户重试）

反例：把 new FileInputStream("config.txt") 包在 try-catch 里静默吞掉，结果配置永远加载失败，日志里却没线索。

参数错、逻辑崩、状态非法，用 RuntimeException

这类异常反映的是程序内部缺陷或非法输入，应该靠校验、测试、设计约束来提前拦截，而不是靠运行时捕获兜底。

• NullPointerException：说明你没做 if (obj != null) 防御，或不该传 null 却传了

• IllegalArgumentException：比如传了个负数给“年龄”字段，这是契约破坏，该在入口校验

• ArrayIndexOutOfBoundsException：下标越界，通常意味着循环条件或边界计算有误

• 自定义异常时，如果想表达“调用方违反了约定”，继承 RuntimeException；如果想表达“这事可能真发生，你得应对”，才继承 Exception

• 别为了“看起来规范”硬把 IllegalArgumentException 改成受检异常——这会让所有调用者被迫写一堆无意义的 try

IDE 提示和日志里怎么快速定位类型

实际 debug 时，光看异常名容易误判，尤其当项目里有大量自定义异常。

• 看堆栈第一行：如果以 java.lang. 开头（如 java.lang.NullPointerException），基本是运行时异常；以 java.io.、java.sql.、javax.naming. 开头的，大概率是受检异常
• 在 IDEA 或 VS Code 中，把异常类名高亮，按 Ctrl+Click 跳转，一眼看到 extends RuntimeException 还是 extends Exception
• 日志中如果只看到 Exception 而没具体类名，说明有人写了 catch (Exception e) —— 这是坏习惯，会把受检和运行时混在一起，掩盖真实问题类型

真正容易被忽略的，是那些“本该在开发阶段暴露，却被层层 catch (Exception e) 吞掉”的运行时异常。它们不会让编译失败，但会让线上行为变得不可预测。