明确异常类型并分层记录日志，使用自定义异常和异常链保留上下文，在全局处理器中统一记录ERROR日志，避免吞异常或重复打印，确保问题可追溯。
在Java开发中，异常处理和日志记录是保障系统稳定性和可维护性的关键环节。合理使用异常抛出与日志记录，能帮助开发者快速定位问题、提升系统的可观测性。以下是实际项目中总结的最佳实践。
明确异常类型，避免泛化处理
Java中异常分为检查型异常（checked）和非检查型异常（unchecked）。应根据业务场景选择合适的异常类型。
- 对于可预见且需要调用方处理的错误（如文件不存在、网络超时），使用检查型异常，强制调用方做出响应。
- 对于程序逻辑错误（如空指针、数组越界），使用运行时异常（RuntimeException），无需强制捕获，但应在文档中说明。
- 避免直接抛出Exception或Throwable，应定义业务相关的自定义异常，如UserNotFoundException，提高代码可读性。
异常信息应包含上下文，便于排查
抛出异常时，提供足够的上下文信息能显著缩短调试时间。
- 在throw语句中加入具体信息，例如：throw new UserNotFoundException("用户ID不存在: " + userId);
- 使用异常链（chained exception）保留原始异常堆栈，如：throw new ServiceException("服务调用失败", e);
- 避免“隐藏”底层异常，确保根因不丢失。
日志记录要分层级，内容清晰
结合SLF4J或Logback等主流日志框架，按不同级别记录日志，避免日志冗余或缺失。
立即学习“Java免费学习笔记（深入）”；
- ERROR：记录未被捕获的异常或严重故障，必须包含异常堆栈。
- WARN：记录可恢复的异常或潜在问题，如重试机制触发。
- INFO：记录关键业务流程的进入/退出，适合运维监控。
- DEBUG/TRACE：用于开发期调试，输出参数、返回值等细节。
示例：
logger.error("订单处理失败，订单ID: {}", orderId, ex);
避免重复记录或静默吞掉异常
常见错误是在捕获异常后仅打印日志又重新抛出，导致日志重复。
- 在最外层统一处理异常（如全局异常处理器），只记录一次ERROR日志。
- 中间层捕获异常时，若需转换异常类型，不应记录日志，交由上层统一处理。
- 绝对禁止catch后不做任何处理（即“吞异常”），这会让问题难以发现。
基本上就这些。关键是保持异常清晰、日志有用，既不过度也不遗漏。不复杂但容易忽略。
