log4j 1.x 中错误方法的区别答案

【问题标题】：Differences between error methods in log4j 1.xlog4j 1.x 中错误方法的区别
【发布时间】：2019-04-17 09:41:32
【问题描述】：

在我工作的项目的日志记录部分，我尝试优化日志管理中显示的错误消息。记录错误消息的编码如下：

String errorMessage =" Problem with server "+"\n"+t.getMessage();
_logger.fatal(errorMessage);

其中t为Throwable对象，_logger为Logger对象，与log4j框架相关。

我想知道的是，如果我使用_logger.fatal(errorMessage, t); 而不是_logger.fatal(errorMessage);，会发生什么变化？如果它们之间有很大的区别，使用哪个更好？

编辑：我刚刚意识到我复制了“致命”示例而不是“错误”。但是我的问题也同样适用于致命问题。

【问题讨论】：

如果你使用_logger.fatal(errorMessage, t); ，你会看到堆栈跟踪，否则只有消息
哪个更好用：这取决于...
如果你真的不想要堆栈跟踪，t.toString() 也可能比t.getMessage() 提供更多信息。这是java.lang.NullPointerException: null 与null 之间的区别。

标签： java logging log4j

【解决方案1】：

几乎所有 Java 日志框架（唉，我们有很多这样的框架......）都支持将 Throwable 作为最后一个参数。

这将导致堆栈跟踪被记录，这对于诊断和解决问题可能非常有用。

如果异常的原因确实已经确定并且打印异常只是不必要的噪音，我永远不会向记录器提供异常。例如这里：

try {
   int port = Integer.parseInt(input);
   // do something with the port
} catch (NumberFormatException e) {
   logger.error("'{}' is not a valid port number: {}", input, e.toString);
}

另一种情况是重新抛出异常（其他东西最终会更详细地记录它）。

但不是“服务器问题”（并且在致命级别不少于）。看起来您希望获得尽可能多的信息。

另请注意，在这些情况下，e.toString() 通常比 e.getMessage() 更好，因为它除了消息之外还包含异常的名称（可能为空）。

【讨论】：