java中catch块重包装业务异常应通过自定义异常类（如businessexception）显式携带errorcode字段，提供getter供统一处理，避免隐含于message；需集中管理错误码（如枚举），映射底层异常为业务码，并保留cause。
在Java中，catch块重新包装业务异常时传递错误码，核心是让新异常能携带原始错误码，并确保调用方能可靠获取。不建议仅靠异常消息（message）隐含错误码，而应通过自定义异常类的字段显式承载。
定义带错误码的业务异常基类
推荐创建统一的业务异常类（如 BusinessException），包含 errorCode（String 或 int）、message 和可选的 details：
- 构造函数支持传入 errorCode + message（或 cause），保证错误码不丢失
- 提供 getter 方法（如 getErrorCode()），供上层统一处理（如日志、HTTP响应封装）
- 避免继承 RuntimeException 后丢失语义；若需检查型异常，可继承 Exception
在 catch 中包装时显式传入错误码
不要依赖原始异常的消息解析错误码。应在捕获后，根据上下文明确指定或映射错误码：
- 若原异常本身就是你的业务异常（如 AccountNotFoundException），直接提取其 getErrorCode()
- 若捕获的是底层异常（如 SQLException），按业务场景映射为有意义的业务错误码（如 "USER_DB_UNAVAILABLE"），而非照搬 SQLState
- 包装示例：throw new BusinessException("PAY_TIMEOUT", "支付超时，请重试", e);
保持错误码语义一致且可维护
错误码不应是硬编码字符串字面量，建议集中管理：
- 使用接口或枚举定义错误码常量（如 ErrorCode.PAY_TIMEOUT），避免散落各处
- 枚举可附带默认消息和HTTP状态码，增强可读性与一致性
- 若错误码需国际化，可在异常构造时传入码，由全局处理器查表渲染对应语言消息
避免常见陷阱
以下做法会削弱错误码的可用性与可维护性：
- 把错误码拼在 message 字符串里（如 "ERR_001: 用户不存在"），导致解析脆弱、难以抽取
- 在包装时忽略原始 cause，丢失堆栈和根因信息（务必调用 super(message, cause)）
- 不同模块使用相同错误码但含义不同，未做命名空间隔离（如用 "USER_NOT_FOUND" 表示账户、设备、订单等不同实体）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
