Java中应封装异常信息，使用自定义运行时异常承载业务语义、错误码、可读消息及原始异常链；通过错误码枚举统一管理，配合参数化消息格式；在DAO、Service、Controller层分层封装，返回标准化API响应并过滤敏感信息。
在Java中封装异常信息，核心是让错误既便于开发排查，又对业务友好。不建议直接抛原始异常（比如NullPointerException或SQLException），而应统一用自定义运行时异常承载业务语义、错误码、可读消息和原始异常链。
定义结构化的错误码枚举
用枚举集中管理所有业务错误场景，每个条目包含唯一编码、简明描述，支持参数化填充：
- 避免硬编码字符串，提升可维护性和国际化扩展性
- 示例：
USER_NOT_FOUND("USR001", "用户不存在，ID={0}") - 配合
MessageFormat.format()实现动态消息生成
编写继承RuntimeException的业务异常类
不强制上层处理，符合多数Web/微服务场景习惯；关键字段包括错误码、消息、原始异常（cause）：
- 提供多个构造方法：仅传错误码、带自定义消息、包装原始异常、支持参数化格式化
- 重写
getMessage()确保返回面向用户的提示，而非堆栈 - 保留
getCause()供日志或调试时追溯底层原因
在关键位置做分层封装
不是所有异常都需要封装，重点在模块边界和对外接口处：
- DAO层捕获
SQLException→ 封装为DataAccessException，附带SQL执行上下文 - Service层校验失败（如手机号格式错误）→
抛出
ValidationException，含字段名与规则 - Controller统一拦截业务异常，转为标准HTTP响应（如400 + {code, message}）
配套返回结果体统一承载异常信息
API响应对象中预留错误字段，避免把异常细节直接暴露给前端：
- 字段如：
status（"error"）、code（"USR001"）、message（"用户不存在，ID=123"）、timestamp - 生产环境关闭
stackTrace输出，调试环境可选开启 - 敏感信息（如数据库密码、路径）必须过滤，不可出现在错误消息中
