规范Java异常处理的关键在于明确受检异常的适用边界、统一转译策略、强制资源管理与日志记录、建立分类命名公约：仅对调用方有能力主动恢复的外部可预期失败（如文件读写、网络超时、DB连接中断）使用受检异常；RPC调用、Web接口、DTO转换等场景应使用非受检异常兜底；禁止为逻辑错误引入受检异常；受检异常穿透至业务层须封装为带业务语义的非受检异常并保留原始cause与上下文；资源操作必须用try-with-resources；捕获后须用SLF4J记录含参数的ERROR日志；自定义异常统一继承RuntimeException，命名体现领域动作与失败原因，并支持业务ID、时间戳、错误码。
团队异常风格不统一，根源往往不在“会不会写try-catch”，而在于缺乏明确的规范共识。Java受检异常（Checked Exception）本身设计意图是强制开发者面对可恢复的外部失败，但若使用不当，反而会引发签名膨胀、掩盖语义、层层throws等反模式。规范团队风格，关键不是禁用受检异常，而是定义清楚“谁该处理、怎么处理、何时转译”。
明确受检异常的适用边界
不是所有外部操作都值得用受检异常——它只适用于那些调用方**有能力且应当主动应对**的可预期失败。
- 推荐场景：文件读写（FileNotFoundException）、网络请求超时（自定义NetworkTimeoutException）、数据库连接中断（SQLException）——这些失败有明确恢复路径（重试、降级、提示用户）
- 慎用/避免场景：内部服务间RPC调用、Web接口层、DTO转换、纯内存计算——此时失败多属系统异常或编程错误，更适合用非受检异常统一兜底
- 特别注意：不要为“可能为空”“参数格式不对”这类逻辑错误引入受检异常，它们应由IllegalArgumentException或NullPointerException表达
统一异常转译策略
当受检异常穿透到业务层或API层时，不应原样抛出，也不应粗暴包装成RuntimeException丢失原始信息。团队需约定标准转译方式：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在Service或Controller入口处，将底层受检异常（如IOException）封装为带业务语义的非受检异常（如FileProcessingException），并保留原始异常作为cause
- 转译时必须注入上下文：例如“解析订单文件[order_20260611.csv]时IO异常”，而非仅“IO异常”
- 禁止出现
catch (Exception e) { throw new RuntimeException(e); }这种无信息转译——它等于丢弃了堆栈和语义
强制资源管理与日志记录规范
受检异常常伴随资源操作（文件、流、连接），团队需同步约束配套行为：
立即学习“Java免费学习笔记（深入）”；
- 所有实现AutoCloseable的资源，必须使用try-with-resources语法，禁止手动finally关闭
- 捕获受检异常后，严禁空catch或仅e.printStackTrace()；必须调用统一日志门面（如SLF4J），记录ERROR级别日志并输出完整堆栈
- 日志模板标准化：例如"【文件导入】用户ID={}，文件名={}，读取失败：{}"，参数顺序固定、占位符命名清晰
建立异常分类与命名公约
避免团队成员随意创建异常类，导致类型泛滥、语义模糊：
- 基础层（DAO/SDK）可保留标准受检异常（如SQLException），但禁止自定义低层级受检异常
- 业务层统一使用继承RuntimeException的自定义异常，命名体现领域动作+失败原因，如InventoryInsufficientException、PaymentValidationFailedException
- 所有自定义异常必须提供含业务ID、时间戳、错误码的构造方法，并支持序列化
