17370845950

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参数保留原始异常，否则丢失调试线索。

• 正确做法：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()获取）