分层异常处理的核心是按职责隔离异常：表现层只暴露用户友好的提示，业务层用语义化异常表达规则（如InsufficientStockException），数据访问层将技术异常统一包装为DataAccessException。
Java异常处理确实需要分层，分层不是为了增加复杂度，而是为了让错误更可读、更可控、更易维护。核心在于：不同层级只关心自己该处理的异常，不该越界捕获或暴露底层细节。
分层异常的核心原则
分层异常体系不是简单地为每层定义新异常类，而是围绕“谁该知道什么”来设计：
- 表现层（Controller）：只暴露用户能理解的提示，如“订单提交失败，请稍后重试”，不抛出 SQLException 或 NullPointerException
- 业务层（Service）：封装具体业务规则异常，如“库存不足”“余额不足”，用自定义业务异常（如 InsufficientStockException）表达语义
- 数据访问层（DAO / Mapper）：将技术异常（如 JDBC 异常、MyBatis SQL 异常）统一转换为业务层可识别的数据访问异常（如 DataAccessException），不直接向上抛原始 SQLException
如何设计分层异常类
推荐采用“基础异常 + 分层子类”结构，避免泛滥定义：
- 定义一个顶层业务异常基类，如 BusinessException（继承 RuntimeException），带 error code、message、timestamp 等通用字段
- 按领域/模块派生子类，如 OrderException、PaymentException，而非按层级命名（如 ServiceException、DaoException）
- 技术异常统一包装：DAO 层捕获 SQLException 后，转为 DataAccessException 并保留 cause，便于排查又不泄露数据库细节
异常传递与转化的关键点
跨层调用时，异常不应“裸奔”，而要适度转化：
立即学习“Java免费学习笔记（深入）”；
- Service 调用 DAO 出错 → 捕获 DataAccessException，判断是否需重试或降级；若属于业务失败（如查不到记录），可转为特定业务异常（如 ProductNotFoundException）
- Controller 接收 Service 抛出的 BusinessException → 统一用 @ExceptionHandler 拦截，返回标准 JSON 错误响应（含 code、message、requestId）
- 不要在 Service 层 try-catch 后吞掉异常或只打日志就返回 null —— 这会让上层无法区分成功与失败
避免常见分层陷阱
分层异常容易陷入的误区：
- 把所有异常都转成 RuntimeException，导致事务回滚失控（@Transactional 默认只对 RuntimeException 回滚）—— 关键业务异常建议显式声明 rollbackFor
- 每层都定义一套“XXXException”，造成类爆炸且语义重复 —— 优先复用语义明确的业务异常，技术异常走统一包装
- 在 Controller 层又 try-catch Service 异常做二次处理 —— 违背单一职责，应由全局异常处理器统一收敛
基本上就这些。分层异常不是堆砌类，而是建立一层层“信息过滤器”：下层提供事实，上层负责解释和应对。设计得当，报错时一眼看出是数据问题、规则问题还是交互问题，调试和协作效率会明显提升。
