17370845950

Java自定义异常的核心是将技术报错转化为业务信号，解决内置异常语义模糊问题，支持分类捕获、携带上下文信息，并依性质分层设计继承体系与构造器。

Java里使用自定义异常，核心是为了让错误更“说人话”、更贴近业务、更好处理——不是为了多写一个类，而是让异常从“技术报错”变成“业务信号”。

解决内置异常语义模糊的问题

Java自带的 IllegalArgumentException、IllegalStateException 等，只告诉你是“参数不对”或“状态不对”，但不说清是“手机号格式错误”还是“用户已被冻结”。这种模糊性会让日志难查、前端提示笼统、协作时反复追问上下文。

• 比如登录失败，抛出 InvalidPasswordException 比抛 IllegalArgumentException 更直接；
• 订单创建失败，用 InsufficientStockException 而非 RuntimeException，调用方一眼明白是库存问题，不是代码写错了。

支持按业务维度分类捕获和处理

统一用 Exception 或 Throwable 捕获，等于把所有问题都塞进一个筐。自定义异常能自然形成继承体系，比如让所有用户相关异常继承 UserException，所有支付异常继承 PaymentException，这样 try-catch 就能分层响应：

• 用户模块异常 → 返回 400 + 提示“请检查账号信息”；
• 支付超时异常 → 自动重试或降级到余额支付；
• 系统级异常（如数据库连接失败）→ 记录告警并返回 503。

携带可扩展的业务上下文信息

标准异常只有 message 和 stack trace，而自定义异常可以轻松增加字段：订单号、用户ID、错误码、请求ID、甚至重试建议。这些信息对排查线上问题、对接监控平台、生成用户友好提示至关重要。

• 例如：OrderException("库存不足", "ORD20251224001", 2003)；
• 配合全局异常处理器，可自动记录日志、上报指标、组装 JSON 响应体。

符合异常设计的合理分层原则

是否强制处理，得看异常性质：

• 业务规则类异常（如“余额不足”“权限不够”）——推荐继承 RuntimeException，不强制上层 try-catch，避免污染主流程；
• 外部依赖类异常（如“短信网关不可用”“第三方证书过期”）——可继承 Exception，提醒调用方必须决策兜底逻辑；
• 所有自定义异常建议提供带 String、String+Throwable、String+code+Throwable 的构造器，兼顾灵活性与规范性。