一、异常处理的设计原则
明确异常分层与分类
在企业级 Java 应用中，推荐将异常分为业务异常、系统异常、以及框架/库异常三层，以实现具备清晰语义的错误传播路径。通过这种分层设计，可以在不同层次对异常进行不同的处理策略，从而提升整体鲁棒性。
统一的异常分类与错误码体系，使得在全链路上进行追踪与聚合分析成为可能。企业级应用应采用一套一致的错误编码规范，如以 BUS-, SYS-, APP- 等前缀区分业务、系统与应用层异常，便于监控与告警。
以下示例展示了基类异常与派生异常的设计思路，以实现语义清晰、可扩展的错误模型：
public class ApplicationException extends RuntimeException {private final String code;public ApplicationException(String code, String message) {super(message);this.code = code;}public String getCode() { return code; }
}public class BusinessException extends ApplicationException {public BusinessException(String message) {super("BUS-0001", message);}
}
统一风格的异常处理语义
在企业级场景中，全局处理风格是提升可维护性的关键：无论在 Controller、Service 还是 DAO 层，只要异常发生，最终都应通过一套统一的格式回传给上游系统。
一致的错误响应格式，有助于前端快速定位问题、并简化日志聚合与告警规则的编写。
跨层传播的策略应遵循：尽量 保留原始异常信息，必要时包装为业务异常以隐藏实现细节，避免暴露敏感信息。以下示例展示了全局异常处理入口的工作要点：
@ControllerAdvice
public class GlobalExceptionHandler {@ExceptionHandler(BusinessException.class)public ResponseEntity handleBusiness(BusinessException ex) {return ResponseEntity.badRequest().body(new ErrorResponse(ex.getCode(), ex.getMessage()));}@ExceptionHandler(Exception.class)public ResponseEntity handleUnknown(Exception ex) {// 记录日志，返回统一的错误码与描述return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(new ErrorResponse("SYS-9999", "系统异常，请联系运维"));}
}
日志、追踪与告警的协同
对于企业级应用，日志的结构化输出、分布式追踪以及告警策略的协同，是提升鲁棒性的核心要素。将异常信息、堆栈踪迹、错误码和上下文信息发送到集中日志系统（如 ELK、OpenTelemetry）有助于快速定位根因。
在日志中应包含关键字段：code、message、requestId、userId、以及异常阶段等，以便进行全链路追踪与故障诊断。
二、企业级应用中的全局异常处理架构
统一异常处理入口的设计
企业级应用通常采用全局异常处理机制来屏蔽底层实现细节，提供一致的错误体验。全局处理入口应覆盖控制器、服务、数据访问等层级，确保未捕获异常也能被归类为已知错误。
全局处理的可观测性要求对异常进行可观测的统计与告警，避免单点异常导致整个系统的不可用。通过集中化的异常转译，可以实现对业务异常的特定处理策略。
下面给出一个典型的全局异常处理框架示例，演示如何将各种异常映射为统一的响应结构：
@ControllerAdvice
public class GlobalExceptionHandler {@ExceptionHandler({ RuntimeException.class, NullPointerException.class })public ResponseEntity handleRuntime(RuntimeException ex) {// 记录堆栈与上下文log.error("Unhandled runtime exception", ex);return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(new ErrorResponse("SYS-9999", "系统异常，请稍后再试"));}
}
日志、追踪与告警的协同
异常处理并非孤立工作，需要与日志和监控系统深度整合。集中日志系统、分布式追踪和告警通道共同构成高可用的观测体系。
在实践中，保持错误码一致性、为每次异常事件附加上下文信息（如请求ID、会话ID、用户ID）是提升排查效率的关键。
三、常用异常类型与处理模式
业务异常与系统异常的区分
将可预见的业务规则违规用作业务异常，例如参数不符合业务约束、某资源不可用等；将不可预计的环境问题、框架异常视为系统异常，以便通过全局处理进行统一归类。
通过异常编码与消息模板，可以实现对前端和接口的一致性沟通，避免暴露内部实现细节。
示例代码展示了如何在业务边界抛出自定义异常，同时让全局处理器进行统一封装：
public class ResourceNotAvailableException extends BusinessException {public ResourceNotAvailableException(String resource) {super("资源 " + resource + " 不可用");}
}
资源管理中的异常处理
对数据库、文件、网络连接等资源的使用，必须在资源安全关闭的前提下处理异常。通过try-with-resources或显式关闭，可以避免资源泄漏以及后续的崩溃。
在 DAO 层和服务层之间，异常传递与包装要保持清晰，避免隐藏原始异常信息，同时为上层提供可诊断的错误码与消息。
下面给出一个典型的数据库访问异常包装示例，展示如何在捕获底层异常后，抛出带有业务语义的异常：
public void updateRecord(Record r) {try (Connection con = dataSource.getConnection()) {PreparedStatement ps = con.prepareStatement("UPDATE ...");// 设置参数并执行int n = ps.executeUpdate();if (n == 0) {throw new BusinessException("更新未影响任何记录");}} catch (SQLException e) {throw new DataAccessException("DB-1001", "数据库访问失败", e);}
}
可恢复与不可恢复的场景
可恢复异常通常发生在业务计算或输入校验阶段，适合返回给调用者，允许本地重试或降级处理。不可恢复异常则应触发全局处理，确保系统进入安全状态并记录必要的诊断信息。
在设计时，应明确哪些异常可以重试、哪些需要降级，以及在何种条件下进行回滚或告警。通过重试策略与回滚控制，可以提升系统的鲁棒性并降低故障影响。
示例：如何在服务层对可恢复异常进行条件重试，并避免无限循环：
public void process() {int attempts = 0;while (attempts < 3) {try {// 业务逻辑break;} catch (TemporaryException e) {attempts++;if (attempts == 3) {throw new BusinessException("处理失败，已重试三次");}// 指数退避Thread.sleep((long) Math.pow(2, attempts) * 100);}}
}
四、鲁棒性提升的实战技巧
幂等性与幂等设计
企业级系统中，幂等性是确保重复请求不带来副作用的核心原则。应通过幂等性密钥、任务标识符、以及数据库层面的约束来实现。
在接口层引入幂等键的设计，可以有效避免重复提交带来的资源浪费或数据污染。
实现示例中，幂等性通常伴随异常处理的整体策略，以确保在网络或服务异常时不会产生重复副作用。
超时、重试与回滚
对外部依赖（如网络服务、消息队列、数据库）的调用，应设置超时阈值，并在异常时采取受控重试与回滚策略，以避免系统级连锁故障。
回滚策略通常结合事务边界与补偿逻辑实现，确保系统状态在异常发生后仍然一致。
以下是一个简化的重试配置示例，展示如何在服务调用异常时进行有限次重试：
public void callExternalService() {int retries = 0;while (retries < 2) {try {externalService.call();return;} catch (ExternalServiceException e) {retries++;if (retries == 2) {throw new BusinessException("外部服务不可用，请稍后重试");}try { Thread.sleep(200 * retries); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); }}}
}
事务边界与异常传播
在包含分布式事务的场景中，异常传播路径需要对事务边界进行明确控制，避免跨服务的隐式回滚导致业务不一致。使用明确的 @Transactional 边界与显式的异常抛出，可以提高事务的可预测性。
合理设计事务边界，确保业务失败时可回滚、成功时可提交，同时对异常进行合适的包装与传递，是提升企业级应用鲁棒性的关键实践。
五、典型代码示例与模式应用
常用异常封装模式示例
通过自定义异常层次，可以将具体异常映射到统一的错误码与消息模板，便于前端快速解析并触发相应的处理逻辑。以下示例展示了在 DAO 层抛出自定义异常的情景：
public List findUsersByRole(String role) {try (Connection con = dataSource.getConnection()) {PreparedStatement ps = con.prepareStatement("SELECT * FROM users WHERE role = ?");ps.setString(1, role);ResultSet rs = ps.executeQuery();// 处理结果集} catch (SQLException e) {throw new DataAccessException("DB-1002", "查询用户失败", e);}
}
自定义异常示例
自定义异常的设计应遵循可读性和可扩展性原则，确保后续新增的业务场景能够快速接入。下面是一个可复用的自定义异常结构：
public class DataAccessException extends RuntimeException {private final String code;public DataAccessException(String code, String message, Throwable cause) {super(message, cause);this.code = code;}public String getCode() { return code; }
}
可观测性友好的日志示例
在异常发生时，输出结构化日志并附带上下文信息，是提升诊断效率的重要手段。
log.error("数据访问异常，code={}, message={}, requestId={}", ex.getCode(), ex.getMessage(), requestContext.getRequestId(), ex);
