java中应通过异常链包装受检异常，用带cause构造函数的运行时异常（如runtimeexception）包裹，并优先选用语义明确的子类；须遍历cause链日志，避免丢弃根因或滥用error。
Java中不建议直接“转化”受检异常为非受检异常，而是通过异常链（cause）包装并重新抛出，既保留原始错误上下文，又规避强制处理要求。核心规范是：用运行时异常（如 RuntimeException 或其子类）包裹受检异常，并将原异常作为 cause 传入构造函数。
必须保留原始异常的 cause
这是异常链的根基。丢弃 cause 就等于丢失关键诊断信息，违反故障可追溯原则。
- ✅ 正确：使用支持
Throwable cause的构造函数，例如new RuntimeException("DB access failed", e) - ❌ 错误：仅用字符串构造，如
new RuntimeException("DB access failed")；或手动设置initCause()（已过时且易遗漏）
优先选用语义明确的运行时异常子类
比裸用 RuntimeException 更具可读性和可维护性。JDK 提供了多个标准子类，应按场景选用：
- 数据访问失败 →
org.springframework.dao.DataAccessException（Spring 场景）或自定义DataAccessException - 配置/资源加载失败 →
IllegalStateException（如配置缺失导致状态非法） - 外部服务调用失败 →
RuntimeException或自定义ExternalServiceException - 不应使用
Error及其子类（如OutOfMemoryError），它们代表不可恢复的 JVM 级问题
避免在公共 API 中隐藏受检异常语义
若方法本意就是可能失败且调用方需感知（如文件读取、网络请求），强行包装成运行时异常会削弱契约表达力，增加调用方排查成本。
- 内部工具类、模板方法、回调执行器等“屏蔽底层细节”的场景适合包装
- 公开的、领域语义清晰的 API（如
UserRepository.findById()）应权衡：若失败属预期业务分支，考虑返回Optional或结果类型（如Result<t></t>），而非异常 - 若仍需异常，建议声明受检异常，或提供两个重载：
findById(...)（抛受检异常）和findByIdUnchecked(...)（包装后抛运行时异常）
日志与监控需穿透异常链
仅打印最外层异常会导致原始根因丢失。记录日志或上报监控时，必须遍历 cause 链。
- ✅ 使用
logger.error("Operation failed", e)（SLF4J/Log4j 支持自动展开 cause） - ✅ 自定义日志逻辑中调用
e.printStackTrace()或ThrowableUtils.getRootCause(e) - ❌ 仅记录
e.getMessage()或e.toString()—— 无法定位根本原因
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
