应使用try-catch捕获具体异常并结合日志框架输出完整堆栈，避免吞异常；优先捕获子类异常，记录信息时使用log.error或warn并传入异常对象，确保错误可追溯；在业务层可将底层异常封装为自定义异常并保留原因链，便于分层排查；生产环境禁止使用System.err，应通过SLF4J/Logback等日志系统管理输出，保证异常可见、可查。
在Java中处理异常时，不仅要确保程序的稳定性，还要便于排查问题。优雅地捕获异常并打印详细信息，关键在于合理使用try-catch结构、记录完整的堆栈轨迹，并结合日志框架进行输出。
使用try-catch捕获特定异常
避免使用catch(Exception e)捕获所有异常，应针对可能发生的具体异常类型进行处理，比如IOException、NullPointerException等。
这样可以更精准地响应不同错误场景，同时保留异常语义。
- 优先捕获子类异常，再捕获父类异常
- 不要忽略异常，即使暂时无法处理也应记录
打印完整的堆栈信息
直接打印e.getMessage()往往信息不足，推荐调用e.printStackTrace()或使用日志框架输出完整堆栈。
立即学习“Java免费学习笔记（深入）”；
但在生产环境中，不应使用System.err输出堆栈，而应交给日志系统管理。
try {
// 可能出错的代码
} catch (IOException e) {
log.error("文件读取失败", e);
}
这种方式会自动打印异常类型、消息和完整堆栈，方便定位源头。
结合日志框架（如Logback/SLF4J）
使用SLF4J + Logback等成熟日志组件，能更好地控制输出格式和级别。
示例：
private static final Logger log = LoggerFactory.getLogger(MyClass.class);
try {
Files.readAllLines(Paths.get("missing.txt"));
} catch (IOException e) {
log.warn("读取配置文件失败，将使用默认值", e);
}
日志框架支持按需开启调试、记录到文件、添加上下文信息，比直接打印更灵活可靠。
考虑包装异常并保留原因链
在业务层捕获底层异常时，可将其作为“原因”封装为自定义异常，既保持语义清晰，又不丢失原始信息。
例如：
} catch (SQLException e) {
throw new UserServiceException("用户查询失败", e);
}
之后通过getCause()仍可追溯原始异常，适合分层架构中的异常传递。
基本上就这些。关键是别吞异常，要留痕迹，用好日志工具，让错误看得见、查得清。
