java异常处理需区分检查型与非检查型异常，避免空catch和掩盖根因，优先捕获具体异常、记录带上下文的日志，用try-with-resources管理资源，并在异常转换时保留cause。
Java异常处理不是“加个try-catch就完事”，关键在于分清错误类型、明确处理责任、保持调用链清晰，并避免掩盖问题或破坏业务语义。
区分检查型异常与非检查型异常
Java强制要求处理检查型异常（Checked Exception），如IOException、SQLException，它们代表可预期的外部问题；而非检查型异常（Unchecked Exception）（即RuntimeException及其子类）代表程序逻辑错误，如NullPointerException、IllegalArgumentException。
- 不要用RuntimeException包装本该声明的检查型异常来逃避编译检查
- 自定义业务异常建议继承RuntimeException（如OrderNotFoundException），除非该异常必须被上层显式处理
- 对数据库、文件、网络等外部依赖，优先捕获具体异常（如SQLException而非Exception），便于针对性恢复或日志记录
避免空catch或只打印e.printStackTrace()
空catch块等于静默吞掉错误，printStackTrace()则缺乏上下文且不便于监控。生产环境必须记录有意义的日志，并考虑是否需要通知、重试或降级。
- 使用SLF4J等日志框架，记录异常堆栈+关键业务参数（如订单ID、用户ID）
- 不要在finally中吞掉异常：若finally里抛出新异常，会覆盖try/catch中的原始异常
- 若确定异常可忽略（极少数场景，如关闭已关闭的流），也应添加注释说明原因
异常转换要保留原始根因
在分层架构中（如Service → DAO），上层不应暴露下层技术细节。但转换异常时需通过cause参数保留原始异常，否则丢失调试线索。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：
throw new ServiceException("下单失败", e); - 错误做法：
throw new ServiceException("下单失败");（丢失e） - Spring等框架的@ExceptionHandler也支持获取原始异常，日志中可通过
e.getCause()逐层追溯
资源管理优先用try-with-resources
涉及InputStream、Connection、Statement等需显式关闭的资源，用try-with-resources替代手动close()，既简洁又避免因异常导致资源泄漏。
- 资源变量必须是final或effectively final
- 多个资源可用分号分隔，关闭顺序与声明顺序相反
- 即使try块中抛出异常，资源仍会自动关闭；若关闭过程也抛异常，会被抑制（可通过
e.getSuppressed()获取）
