编码时使用log4j级别的最佳做法是什么? 我的意思是我们何时使用INFO日志记录,何时使用DEBUG日志记录/ ERROR日志记录等。
答案 0 :(得分:18)
一般来说,我遵循以下准则:
答案 1 :(得分:10)
我的基线始终是 INFO 级别等同于System.out,而 ERROR 等同于System.err。
DEBUG - 在这里,您可以放置所有的跟踪信息,特别是当您的“舒适度”为system.out时,您不希望看到的信息。
INFO - 将此一个用于常规消息,进度消息,用于与应用程序相关的消息,但不用于跟踪。
WARN - 提供错误,可能是意外的警报或使用变通方法的警报,但应用程序仍可继续(套接字超时/重试,无效的用户输入等)。< / p>
错误 - 有关阻止您的应用正常继续运行的问题的提醒,例如:数据库已关闭,缺少引导程序配置。
编写库时常见的错误是使用ERROR级别来指示调用应用程序(使用库的代码)的问题,而不是指示库本身内的实际错误。例如,请参阅此hibernate错误 - &gt; http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731
这真的很烦人,因为来自ERROR级别的消息确实难以抑制,因此仅使用它们来表示您自己的代码存在问题。
全部 - 我真的不使用这个,它实际上与DEBUG或TRACE相同。
答案 2 :(得分:7)
最好的学习方法就是举例。阅读一些开源的东西,比如哦,Tomcat或你应用领域的任何东西,看看你看到了什么。
答案 3 :(得分:2)
尽管这个问题很老,但这确实是每个开发人员应该知道的重点,我强烈建议您查看Apache log4j的官方页面。
此外,我发现并且有用的图像完美地描述了这一点,log4jImage来自supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html
答案 4 :(得分:2)
<强> TRACE 强>: 最低级别的日志。提供最详细的信息。
<强> DEBUG 强>: 这里的日志声明旨在帮助开发人员。详细的申请状态。
<强> INFO 强>: 一般商业信息。申请的进展和状态
<强> WARN 强>: 有关意外事件的警告。这些不够严重,不足以中止您的申请。
错误: 您的申请中存在严重问题。
在不同环境中启用正确级别的日志记录同样至关重要。
答案 5 :(得分:0)
错误日志记录应始终打开。
在追踪问题/错误时,应该启用INFO + DEBUG 。
答案 6 :(得分:0)
对于其他人提到的,我会添加TRACE和FATAL级别,前者适用于非常详细的日志记录,后者则表示总显示停止。如上所述,有关于如何使用关卡的一般指导方针。但是,最重要是您将如何使用它以及 USERS 将如何解释它们。您需要关注问题的级别,因此请确定您的案例中的问题。您的用户几乎不需要跟踪或调试语句,但他们肯定会想要解决问题并向您报告。
答案 7 :(得分:0)
以下是我使用的一些指导原则:
DEBUG :仅供开发人员注意的日志记录 - 变量内容,比较结果以及其他有助于调试业务逻辑的信息。
INFO :任务X的高级信息现已完成或某些规则已满足,以下是我将要执行的规则。
WARN :可能存在问题,但对业务逻辑流程造成任何实际损害并不严重。例如,某些变量有时可能为null但我们不一定需要它,或者我们可以以某种方式解决它。与此同时,我们仍然想了解它,以防万一我们被告知以后我们需要找到它的例子或更仔细地调查它为什么会发生。
错误:一个严重的问题,肯定需要进一步调查,但不够严重,不足以阻止应用程序完成手头的任务。
致命:一个非常严重的意外问题,我们无法解决或从中恢复,甚至可能阻止应用程序执行有用的操作。