Java中的RuntimeException与Exception的区别_技术教程

RuntimeException 是 unchecked 异常，编译器不强制处理；其子类及 Error 的子类均属 unchecked，而继承 Exception（非 RuntimeException）的为 checked 异常；是否受检取决于继承关系而非名称或发生时机。

RuntimeException 是 unchecked 异常，编译器不强制处理

Java 把 Exception 分成两大类：checked（受检）和 unchecked（非受检）。RuntimeException 及其子类属于 unchecked，意味着你调用一个可能抛出 NullPointerException 或 ArrayIndexOutOfBoundsException 的方法时，编译器不会报错，也不要求你写 try-catch 或

声明 throws。

而普通 Exception（比如 IOException、SQLException）是 checked 的——不处理就编译失败。

这是语言设计上的区分：checked 异常代表「预期外但可恢复的外部问题」（如文件不存在、网络超时），应由调用方显式决策；
unchecked 异常代表「程序逻辑错误」（空指针、越界、类型转换失败），本不该发生，修复代码比捕获更合理；
别为了过编译而随便加 catch (Exception e) { }，这会掩盖真正的 bug。

继承关系决定行为，不是名字决定的

是否为 unchecked，只看它是不是 RuntimeException 或 Error 的子类。哪怕你自定义一个叫 MyBusinessException 的异常，只要它继承 Exception（而非 RuntimeException），它就是 checked 异常。

反过来说，如果你继承 RuntimeException 写了个 ValidationFailedException，它就自动变成 unchecked，无需 throws 声明。

常见误区：以为“运行时异常”只发生在运行期——其实所有异常都发生在运行期，关键在编译期是否检查；
Exception 是父类，RuntimeException 是它的直接子类；
不要因为某个异常类名里没 “Runtime” 就误判它是否受检，查源码或 IDE 的继承树最可靠。

该捕获哪个？看能否有意义地恢复

面对 RuntimeException，多数情况不该捕获——比如 NullPointerException 暴露的是你忘了判空，补上 if (obj != null) 才是正解，而不是包一层 try-catch 吞掉它。

但也有例外：框架层（如 Spring MVC）会统一捕获 RuntimeException 转成 HTTP 500；或者你在解析用户输入时，用 NumberFormatException 判定输入格式非法，这时捕获反而更清晰。

能预判并主动规避的，优先改逻辑（如判空、校验集合 size）；
属于用户输入或外部数据导致的「可预期的失败」，且有明确 fallback 行为（如返回默认值、提示友好错误），可以捕获特定 RuntimeException；
永远避免 catch (Exception e) 或 catch (RuntimeException e) 空处理，除非你真要记录日志后重新抛出。

自定义异常时，选 Exception 还是 RuntimeException？

取决于你希望调用方「必须处理」还是「自行决定是否处理」。例如：

public class InsufficientBalanceException extends Exception { ... } // 调用方必须 try 或 throws
public class InvalidTokenException extends RuntimeException { ... } // 调用方可选择忽略

微服务中常见做法：BusinessException 继承 RuntimeException，配合全局异常处理器统一返回 JSON 错误；而涉及 IO、资源访问的异常（如 ConfigLoadException）若希望启动阶段就失败，可设为 checked。

如果异常表示「调用方应该知道并响应」，用 checked；
如果异常表示「调用方很难提前预防，出了就该修代码」，用 unchecked；
Spring 的 DataAccessException 体系全继承 RuntimeException，就是为了不让 DAO 层代码被 throws 污染——这个设计取舍很典型。

最易被忽略的一点：同一个异常类，在不同模块语义可能不同。比如 IllegalArgumentException 在工具类里是 unchecked 逻辑错，在 API 入口层却可能被当作用户参数错误来捕获并返回 400 ——关键不在它是什么类，而在你用它表达什么意图。