不要吞掉异常，应避免空catch块、使用日志记录并合理抛出，包装异常时保留原始信息，优先使用try-with-resources防止异常掩盖，并在日志中补充业务上下文以提升排查效率。
在Java开发中，异常处理不当，特别是“吞掉异常”（即捕获了异常但没有正确处理或记录），会导致程序行为不可预测、问题难以排查。为了避免这类问题，需要遵循一些关键实践。
1. 不要空捕获异常
最常见导致异常被吞的问题是空的catch块：
错误示例：
try {
riskyOperation();
} catch (IOException e) {
// 什么也不做
}
这种写法让异常悄无声息地消失，调用者无法得知操作失败。
正确做法：至少打印日志或重新抛出。
try {
riskyOperation();
} catch (IOException e) {
logger.error("riskyOperation failed", e);
}
2. 避免只打印不抛出
有时开发者会打印堆栈但不再抛出，这仍然可能掩盖问题：
立即学习“Java免费学习笔记（深入）”；
潜在问题示例：
try {
processFile();
} catch (FileNotFoundException e) {
e.printStackTrace(); // 可能被忽略，尤其在生产环境
}
printStackTrace输出到标准错误流，在多数服务器环境中不易监控。
建议：使用日志框架并考虑是否需要向上层传达错误。
try {
processFile();
} catch (FileNotFoundException e) {
logger.warn("File not found, using default config", e);
throw new IllegalStateException("Config load failed", e); // 包装后抛出
}
3. 正确使用异常包装
当捕获受检异常但当前方法不想声明抛出时，可以包装为运行时异常，但必须保留原始异常：
try {
legacyApiCall();
} catch (LegacyCheckedException e) {
throw new RuntimeException("Unexpected error from legacy system", e);
}
这样既简化了调用方处理，又保留了完整的堆栈信息，便于调试。
4. 在finally或try-with-resources中避免掩盖异常
如果try块抛出异常，而finally块也抛出异常，原始异常可能被覆盖。
问题场景：
InputStream in = openStream();
try {
parse(in);
} finally {
in.close(); // 如果close()抛出异常，parse()的异常可能丢失
}
解决方案：使用try-with-resources，它会自动处理异常压制。
try (InputStream in = openStream()) {
parse(in);
}
资源关闭异常会被作为“被压制的异常”附加到主异常上，可通过getSuppressed()获取。
5. 记录上下文信息
仅记录异常本身可能不足以定位问题。应补充业务上下文：
try {
processOrder(orderId);
} catch (PaymentException e) {
logger.error("Payment failed for order: {}", orderId, e);
throw e;
}
加入orderId等关键信息，极大提升排查效率。
基本上就这些。关键是：别让异常静默消失，确保可观察、可追踪、有上下文。
