logger系统异常日志打印问题

记录系统错误日志，是用来排查错误的一种有效手段，根据错误的堆栈信息，我们能很快的定位到错误点，从而直接解决问题。但是有时候错误的日志记录方式，则很难达到这个效果，反而浪费了很多时间。

因为系统错误日志的问题带来了很多麻烦，所以特定梳理了一下关于记录日志的几个问题。

1、程序关键位置，未做异常处理。

比如页面跳转时，做了其他操作，未进行try catch处理，一旦其中抛出异常，则该次请求则会停止响应。

界面上的表现为：

页面跳转一片空白

前端显示请求返回500错误码

原因是代码中未做异常捕获，直接将异常抛出给主程序了

如果是控制台启动应用，则还能看到错误信息

如果是使用服务启动的，错误信息无从找起

要么换成控制台启动，要么还原现场环境到本地排查效率极其低下，浪费不少时间。

2、进行了异常捕获处理，但是在catch中仅使用了e.printStackTrace();

这种情况和情况一类似，e.printStackTrace()是将错误的堆栈信息打印到控制台，所以排查错误必须要有控制台。

3、使用了log4j记录日志，采用了logger.error(e)、logger(e.getMessage())方式

这种情况下，两种方法都不能够打印完整的错误堆栈信息

需要使用logger("错误：",e)的方式才可行

根据方法重载特性，当只输入一个参数时，此对象会被当做Object进行打印输出，如果是Exception e的话，这里直接就toString()。

/**
 * Logs a message object with the {@link Level#ERROR ERROR} level.
 *
 * @param message the message object to log.
 */
void error(Object message);

根据方法重载特性，当第二个参数为Throwable时，会打印出异常信息，并且包含异常堆栈信息。

/**
 * Logs a message at the {@link Level#ERROR ERROR} level including the stack trace of the {@link Throwable}
 * <code>t</code> passed as parameter.
 *
 * @param message the message object to log.
 * @param t the exception to log, including its stack trace.
 */
void error(String message, Throwable t);　　

根据方法重载特性，当第二个参数为Object时，会根据占位符进行替换并打印出错误日志。

/**
 * Logs a message with parameters at error level.
 *
 * @param message the message to log; the format depends on the message factory.
 * @param p0 parameter to the message.
 */
void error(String message, Object p0);