java中正确处理业务异常需区分技术异常与业务异常，主动抛出自定义异常并由上层统一拦截响应，避免盲目catch；业务异常应设计为checked或runtimeexception，精准捕获、分层处理，配合全局异常处理器实现一致可观测的错误响应。
在 Java 方法中正确捕获并处理业务异常，核心是区分“技术异常”和“业务异常”，不混用、不掩盖、不忽略语义。业务异常不是程序 bug，而是业务规则被违反时的明确反馈，比如“余额不足”“订单已取消”“用户未实名认证”。它应该用自定义异常主动抛出，并由上层统一感知和响应，而不是靠 try-catch 盲目兜底。
明确业务异常的本质：不是错误，是流程分支
业务异常 ≠ 程序崩溃。它是业务逻辑中预设的合法状态转移失败，应设计为 受检异常（Checked Exception）或运行时异常（RuntimeException），取决于团队约定和调用方是否必须显式处理：
- 若该异常要求调用方强制决策（如“支付失败需跳转退款页”），建议继承
Exception，强制用try-catch或throws声明 - 若该异常属于高频、可控、无需强制拦截的业务拒绝（如“活动未开始”“库存不足”），可继承
RuntimeException，更轻量且符合 Spring 等框架默认处理习惯 - 避免直接 throw new Exception() 或 catch (Exception e) —— 丢失业务语义，难以定位和分类
在方法中主动抛出，而非被动捕获
真正“处理”业务异常的位置通常不在抛出处，而在更高层（如 Controller 或 Service 调用方）。方法内部只需做两件事：
- 校验业务前提条件，不满足时立即抛出自定义异常，附带关键上下文（如订单号、用户ID）
- 不把业务判断逻辑塞进 try 块——例如“查库存→扣减→更新订单”是一连串业务操作，异常应来自业务规则本身，而非
NullPointerException这类技术问题 - 示例：
if (order.getStatus() == OrderStatus.CANCELLED) {<br> throw new BusinessException("订单已取消，无法发货", "ORDER_CANCELLED", orderId);<br>}
捕获要精准，处理要分层
只有在你有能力、有职责、有上下文去响应这个业务异常时，才在当前方法中 catch。常见合理场景包括：
- 重试逻辑：对“库存扣减失败”捕获后，等待 100ms 再试一次
- 降级处理：捕获“优惠券服务不可用”，改用默认折扣策略
- 聚合响应：在一个批量操作中，单条失败不中断整体，收集错误信息统一返回
- 注意：catch 后不要只写
e.printStackTrace()，至少记录结构化日志（含 errorCode、traceId、业务参数）
配合框架统一拦截，避免处处 try-catch
在 Web 应用中，90% 的业务异常不应在每个 Service 方法里手动捕获，而应交给全局异常处理器：
- Spring 中用
@ControllerAdvice + @ExceptionHandler拦截自定义业务异常，统一转为 HTTP 400 或特定 JSON 错误体 - 确保异常类包含
errorCode、message、details等字段，便于前端识别和用户提示 - 这样既保持业务方法干净（专注逻辑），又保障错误响应一致、可观测
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
