重构异常规范的关键是保持异常行为清晰可追溯，需统一分类分层、收敛处理、保留上下文；各层职责分明，工具类封装需干净，异常链与消息必须保真，辅以工具链固化规范。
重构时保持异常规范一致，关键不是“不改异常”，而是让异常行为在结构变化中依然清晰、可追溯、不退化。重点在于统一归属、收敛处理、保留上下文，而不是机械地保留原有 try-catch 块。
统一异常分类与分层职责
重构前先明确各层对异常的预期责任：
- DAO/数据访问层：只抛出或转换为受检异常（如 DataAccessException），不捕获 SQLException 后静默吞掉
- Service 层：主动抛出自定义业务异常（如 InsufficientBalanceException），不把 RuntimeException 包装成新异常再抛出
- Controller/Web 层：不自行 catch 业务异常，交由 @ControllerAdvice 统一拦截并转为标准 HTTP 响应
- 工具类或 SafeCall 封装：内部统一记录日志 + 设置默认值/重试策略，对外暴露干净接口，不泄露底层异常类型
重构中避免异常逻辑被“稀释”或“丢失”
常见退化场景及应对方式：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 提取方法时，原方法里有 try-catch，新方法不能变成 void 方法+空 catch——应把异常声明向上抛，或封装为统一返回类型（如 Result<T>）
- 合并重复校验逻辑时，别把 IllegalArgumentException 改成 return null 或 throw new RuntimeException("check failed")——仍用语义明确的自定义异常，如 InvalidOrderException
- 用对象替代长参数列表时，构造函数中的参数校验失败，仍应抛出 IllegalArgumentException，但消息需含上下文，如 "Invalid order amount: must be > 0, got -12.5"
- 替换 if-else 为策略模式后，各 Strategy 实现中发生异常，不应各自写 log.error(...) ——统一由模板方法兜底捕获并包装为 StrategyExecutionException
异常信息与堆栈链必须全程保真
无论怎么拆、合、封装，以下两点不可妥协：
立即学习“Java免费学习笔记（深入）”；
- 所有包装异常必须传入原始 cause，禁止丢弃：new BusinessException("Failed to process payment", e)
- getMessage() 内容必须在构造时确定，不调用外部方法；模板字符串用 String.format 安全填充，不拼接敏感字段
- 日志记录和异常消息要各自完整：log.error("Payment service call failed for order {}", orderId, e) 和 e.getMessage() 都应能独立说明问题
- 自定义异常类必须显式覆写 getMessage()，且仅基于构造参数生成，不抛新异常、不查数据库、不格式化失败兜底
借助工具固化规范边界
人工容易疏漏，用机制保障一致性：
- 启用阿里巴巴 Java 规范插件，开启 Blocker/Critical 级异常规则检查（如“禁止捕获 Exception”“禁止空 catch”“必须保留 cause”）
- 在 CI 流程中集成 Checkstyle 或 PMD，配置 rule：禁止 throws Exception、禁止 catch (Throwable)、强制自定义异常命名以 Exception 结尾
- 建立团队级异常基类（如 BaseBusinessException），要求所有业务异常继承它，并在构造器中强制传入错误码和上下文参数
- 对高频资源操作（如文件、流、连接），重构时一律改用 try-with-resources，避免因结构调整漏掉 finally.close()
