继承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）点进异常类源码，一眼看清父类链；别猜，查继承树最可靠
业务异常该选哪个？看责任归属
这不是语法题，是设计题。核心就问自己一句：这个异常发生时，谁该负责处理？
立即学习“Java免费学习笔记（深入）”；
- 如果答案是「调用我的方法的人」——比如他该根据文件不存在（
FileNotFoundException）决定是新建还是报错，那就继承Exception - 如果答案是「写我这个方法的人」——比如他传了负数给一个只接受正数的
setId(int id)方法，那应该继承RuntimeException（如IllegalArgumentException） - 容易踩的坑：把所有业务异常都塞进
RuntimeException，结果关键流程（如支付扣款失败）没人捕获，系统静默跳过；或者全塞Exception，导致满屏throws和无意义try-catch，掩盖真正需要关注的路径
RuntimeException 子类统一包装，由全局异常处理器拦截；而内部服务间调用、DAO 层等涉及外部资源的地方，仍保留 checked 异常来强制上游感知风险。这个边界划在哪，比语法本身更重要。 
