Exception和RuntimeException的区别详解

一分耕耘，一分收获！既然打开了这篇文章《继承Exception和RuntimeException的区别》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

继承Exception是checked异常，必须try-catch或throws；继承RuntimeException是unchecked异常，可不处理；判断依据唯看继承树，非类名；业务异常选型取决于责任归属。

继承 Exception 就必须处理，否则编译失败

只要你的自定义异常类 extends Exception（且不是 RuntimeException 的子类），它就是 checked 异常。Java 编译器会强制你面对它：调用可能抛出该异常的方法时，要么用 try-catch 捕获，要么在方法签名里加 throws MyBusinessException 向上传递。

• 常见错误现象：unreported exception MyBusinessException; must be caught or declared to be thrown
• 适用场景：外部可恢复问题，比如「用户上传的 Excel 格式非法」「第三方 API 返回 401」——这类情况调用方理应知情并决策（重试？提示？降级？）
• 注意陷阱：别为了过编译而写 catch (Exception e) { } 空吞异常，这会让真实问题静默消失

继承 RuntimeException 就可以不处理，编译器不管

extends RuntimeException 的异常是 unchecked 的，编译器完全不干预。你可以随心所欲地 throw new ValidationFailedException("邮箱格式错误")，调用方爱捕获不捕获，爱声明不声明。

• 常见错误现象：代码能编译通过，但运行时突然崩溃，堆栈里冒出你自定义的异常名——说明它没被任何地方兜住
• 适用场景：纯逻辑错误或非法输入，比如「传了 null 参数给不允许为空的方法」「状态机当前状态不允许执行该操作」——这类问题本该在开发/测试阶段暴露，不该靠线上 try-catch 救火
• 性能影响：无额外开销；RuntimeException 子类和普通对象创建成本一致，别信“运行时异常更慢”的传言

别看名字，看继承树才是唯一判断标准

是否受检（checked）跟类名里有没有 “Runtime” 完全无关。关键只有一条：它是不是 RuntimeException 或 Error 的直接/间接子类？

• 反例：你写个 class MyIoException extends Exception，哪怕叫 “IoException”，它仍是 checked 异常，必须处理
• 正例：你写个 class UserNotFoundException extends RuntimeException，哪怕名字里没 “Runtime”，它也是 unchecked，无需 throws
• 实操建议：在 IDE 里按住 Ctrl（或 Cmd）点进异常类源码，一眼看清父类链；别猜，查继承树最可靠

业务异常该选哪个？看责任归属

这不是语法题，是设计题。核心就问自己一句：这个异常发生时，谁该负责处理？

• 如果答案是「调用我的方法的人」——比如他该根据文件不存在（FileNotFoundException）决定是新建还是报错，那就继承 Exception
• 如果答案是「写我这个方法的人」——比如他传了负数给一个只接受正数的 setId(int id) 方法，那应该继承 RuntimeException（如 IllegalArgumentException）
• 容易踩的坑：把所有业务异常都塞进 RuntimeException，结果关键流程（如支付扣款失败）没人捕获，系统静默跳过；或者全塞 Exception，导致满屏 throws 和无意义 try-catch，掩盖真正需要关注的路径

实际项目里，多数团队会约定：对外暴露的接口层异常（如 REST API 返回码）用 RuntimeException 子类统一包装，由全局异常处理器拦截；而内部服务间调用、DAO 层等涉及外部资源的地方，仍保留 checked 异常来强制上游感知风险。这个边界划在哪，比语法本身更重要。

理论要掌握，实操不能落！以上关于《Exception和RuntimeException的区别详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！