该抛异常的三种典型场景是：违反业务规则、资源不可用且无法自动恢复、参数明显非法且非调用方可控；不该抛异常的误区包括用异常控制流程、包装异常丢失上下文、对可预期失败沉默处理。
Java中该不该抛异常，关键看“这件事是不是调用方本应预料并处理的意外情况”。不是所有错误都要抛异常，也不是所有异常都该由你来抛——设计不合理会导致调用方无所适从，或掩盖真正问题。
该抛异常的三种典型场景
以下情况建议明确抛出异常（通常选受检异常 Exception 或运行时异常 RuntimeException，视语义而定）：
- 违反业务规则：比如用户注册时邮箱已存在、订单支付金额为负、库存不足发货。这类错误语义清晰，调用方理应感知并引导用户修正。
- 资源不可用且无法自动恢复：如数据库连接超时、远程服务不可达、配置文件缺失。这类问题不属于程序逻辑错误，但当前操作无法继续，需中断流程并交由上层决策（重试？降级？告警？）。
-
参数明显非法且非调用方可控：例如传入 null 但方法契约明确要求非空（可用
@NonNull+Objects.requireNonNull()主动抛NullPointerException），或日期字符串格式严重错误（如 "2024-13-01"）。注意：普通校验失败（如密码长度不够）更适合返回错误码或封装结果对象，而非强制抛异常。
不该抛异常的常见误区
滥用异常会破坏代码可读性与性能，也违背异常的设计初衷（表示“异常”，而非“常规分支”）：
-
用异常控制流程：比如用
NoSuchElementException替代Optional.isPresent()判断，或用ParseException检查字符串是否为合法数字。这属于典型的“把if写成try-catch”，既低效又难维护。 -
包装底层异常却不增加上下文：直接
throw new RuntimeException(e)丢弃原始堆栈和原因，等于把调试线索一把火烧掉。应使用带 cause 的构造函数，或至少在消息中说明“在执行XX操作时发生XX异常”。 -
对可预期的失败沉默处理：比如文件不存在时返回 null 而不抛
FileNotFoundException，导致后续NullPointerException在更深层爆发，定位困难。该明确失败就明确失败。
异常类型选择：受检 vs 非受检
核心判断标准是：调用方是否必须、也有能力在编译期处理它？
立即学习“Java免费学习笔记（深入）”；
-
选受检异常（Exception）：当失败是外部环境导致、概率较高、且调用方大概率需要针对性处理时。例如
IOException（文件读写）、SQLException（数据库操作）。它强迫开发者思考“出错了怎么办”，适合系统级、跨边界操作。 -
选非受检异常（RuntimeException）：当失败源于编程错误、参数违规或不可恢复的内部状态时。例如
IllegalArgumentException（参数错）、IllegalStateException（状态错）、自定义的BusinessException（业务规则违例）。它不强制捕获，避免污染正常逻辑，但要求文档写清触发条件。
设计自定义异常的实用建议
别为了“高大上”而自定义，但真需要时请守住三个底线：
-
命名体现语义：用
UserAlreadyExistsException，而不是笼统的ServiceException；用InsufficientBalanceException，而不是AccountException。 -
提供必要上下文：在构造函数中接收关键信息（如用户ID、订单号、错误码），并在
getMessage()或独立方法中暴露，方便日志记录和前端提示。 -
保持继承合理：业务类异常通常继承
RuntimeException；若需强制处理，再考虑继承Exception。避免多层无意义继承（如 AException → BException → CException）。
异常不是错误日志，也不是流程开关，而是契约的一部分——它告诉调用方：“这事超出了我的正常职责范围，你得接手了。” 设计时多问一句：这个异常，是让别人更好处理问题，还是只为了让自己少写一行 if？
