有不同的方式记录消息,按死亡顺序排列:

致命的错误警告信息调试,调试跟踪

我如何决定何时使用哪个?

什么是好的启发式方法?


当前回答

正如其他人所说,错误是问题;警告是潜在的问题。

在开发中,我经常使用警告,在警告中,我可能会放置相当于断言失败,但应用程序可以继续工作;这使我能够发现这个案子是否真的发生过,或者这是我的想象。

但是的,它归结到恢复性和现实性方面。如果你能恢复,那可能是一个警告;如果它导致某个东西实际失败,那就是一个错误。

其他回答

可以从中恢复的警告。错误你不能。这是我的启发,其他人可能有其他想法。

例如,假设您在应用程序中输入/导入名称“Angela Müller”(注意u上的元音变音)。您的代码/数据库可能仅为英文(尽管它可能不应该在这个时代),因此可能会警告所有“不寻常”字符都已转换为普通英文字符。

与之形成对比的是,尝试将信息写入数据库,并连续60秒返回网络关闭消息。这与其说是警告,不如说是错误。

顺便说一句,我非常喜欢捕捉一切,然后过滤信息。

如果您在“警告”级别捕获,并希望获得与警告相关的一些调试信息,但无法重新创建警告,会发生什么情况?

捕获所有内容并稍后过滤!

即使对于嵌入式软件,这也是正确的,除非你发现你的处理器跟不上,在这种情况下,你可能需要重新设计你的跟踪以使其更高效,或者跟踪干扰了时间(你可能会考虑在一个更强大的处理器上调试,但这会带来另一种蠕虫)。

捕获所有内容并稍后过滤!!

(顺便说一句,捕获一切也很好,因为它让您可以开发工具来做更多的工作,而不仅仅是显示调试跟踪(我从中绘制了消息序列图,以及内存使用情况的直方图。它还为您提供了一个基础,以便在将来发生错误时进行比较(保留所有日志,无论是通过还是失败,并确保在日志文件中包含内部版本号))。

根据RFC 5424,系统日志协议(IETF)-第10页:

每个消息优先级也有一个十进制严重性级别指示符。下表中描述了这些参数及其数值价值观严重性值必须介于0到7之间(含0到7)。数值严重性密码0紧急情况:系统不可用1警报:必须立即采取行动2临界:临界条件3错误:错误条件4警告:警告条件5注意:正常但重要的情况6信息:信息性消息7调试:调试级别消息表2。Syslog消息严重性

我一般同意以下约定:

跟踪-只有当我“跟踪”代码并试图找到函数的某一部分时。调试-对开发人员(IT、系统管理员等)以外的人有诊断帮助的信息。信息-要记录的一般有用信息(服务启动/停止、配置假设等)。我想随时提供信息,但在正常情况下通常不关心。这是我的开箱即用配置级别。警告-任何可能导致应用程序异常的情况,但我会自动恢复。(例如从主服务器切换到备份服务器、重试操作、丢失辅助数据等)错误-任何对操作(而不是服务或应用程序)致命的错误(无法打开所需的文件、丢失的数据等)。这些错误将迫使用户(管理员或直接用户)进行干预。这些通常是为不正确的连接字符串、丢失的服务等保留的(在我的应用程序中)。致命-强制关闭服务或应用程序以防止数据丢失(或进一步数据丢失)的任何错误。我只为最令人发指的错误和保证存在数据损坏或丢失的情况保留这些。

塔科·扬·奥辛加的回答非常好,而且非常实用。

我同意他的观点,尽管有些不同。

在Python上,只有5个“命名”日志级别,所以我是这样使用它们的:

调试——对故障排除很重要的信息,通常在正常的日常操作中被抑制信息——日常操作,作为程序按设计执行功能的“证明”警告——超出名义但可恢复的情况,*或*遇到可能导致未来问题的事情错误——发生了一些需要程序执行恢复的事情,但恢复成功。不过,程序可能没有处于最初预期的状态,因此程序用户需要进行调整关键——发生了无法挽回的事情,程序可能需要终止,以免每个人都生活在罪恶的状态中