三层架构中自定义异常通过自然上抛、分层封装和统一拦截实现：各层定义专属异常类，不捕获无明确处理意图的异常，controller层依赖全局处理器转化响应，异常需携带上下文信息。

自定义异常在三层架构中不是“手动传递”，而是通过自然上抛 + 分层封装 + 统一拦截实现的。关键不在于怎么“传”，而在于每一层该定义什么、抛什么、拦什么。

每层定义专属异常，明确职责边界

DAO 层、Service 层、Controller 层应各自定义继承体系清晰的异常类，比如：

• DAO 层：定义 DaoException（继承 RuntimeException），封装数据库连接失败、SQL 语法错误、主键冲突等底层问题；
• Service 层：定义 BusinessException（也继承 RuntimeException），如 UserAlreadyExistsException、InsufficientBalanceException，表达业务规则不满足；
• Controller 层：一般不定义新异常，而是接收下层异常，并交由全局处理器统一响应；也可定义极少数与 HTTP 协议强相关的异常（如 InvalidRequestException）。

所有自定义异常建议共用一个根异常（如 BaseException），便于后续统一捕获和识别。

异常不捕获，除非有明确处理意图

各层对异常的默认策略是不吞掉、不静默、不空 catch：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• DAO 层遇到 SQLException，直接包装为 DaoException 抛出，不 try-catch 记录后返回 null；
• Service 层调用 DAO 出错，可选择原样上抛，或根据上下文补充业务语义（例如：“查询用户失败” → “用户不存在或系统异常”），再以 BusinessException 形式抛出；
• Service 层自己触发的业务校验失败（如用户名已注册），应主动 throw new UserAlreadyExistsException()，而不是用 if-else 返回错误码。

只有当某一层能完全消化并闭环处理**该异常时才捕获**——例如 Service 层调用第三方支付接口失败，降级走本地记账，则可 catch 并转为内部成功流程；否则一律上抛。

Controller 层只做拦截和转化，不做业务判断

Controller 本身不写 try-catch 处理具体异常类型，而是依赖全局异常处理器（如 @RestControllerAdvice）：

• 捕获 BusinessException → 记 WARN 日志，提取错误码和提示语，返回标准 JSON（如 {"code":1001,"msg":"用户名已存在"}）；
• 捕获 DaoException 或 NullPointerException 等系统异常 → 记 ERROR 日志（含 URL、参数、用户 ID），返回通用提示（如 {"code":5000,"msg":"服务暂时不可用"}）；
• 避免在 Controller 方法里对不同异常分别写多个 catch 块——这会破坏分层抽象，也让异常流失去统一治理能力。

异常信息要携带上下文，不能只留空消息

自定义异常构造时，应支持传入业务标识、错误码、原始异常等：

• 推荐构造函数： BusinessException(int code, String message, Throwable cause)；
• DAO 异常可附带 SQL 片段、执行耗时；
• Service 异常可绑定订单号、用户 ID，方便日志追踪；
• 所有异常最终在全局处理器中被结构化输出，前端无需解析堆栈，运维可通过错误码快速定位层级和场景。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南