有不同的方式记录消息,按死亡顺序排列:
致命的错误警告信息调试,调试跟踪
我如何决定何时使用哪个?
什么是好的启发式方法?
有不同的方式记录消息,按死亡顺序排列:
致命的错误警告信息调试,调试跟踪
我如何决定何时使用哪个?
什么是好的启发式方法?
当前回答
如果你能从问题中恢复过来,那就是一个警告。如果它阻止了继续执行,那就是一个错误。
其他回答
在此之前,我已经构建了以下系统:
错误-表示出现了严重错误,特定线程/进程/序列无法继续。需要一些用户/管理员干预警告-有些事情不正确,但过程可以照常进行(例如,一组100个作业中的一个作业失败,但剩余的作业可以处理)
在我所构建的系统中,管理员都在接受指示,以应对错误。另一方面,我们将观察警告,并确定每种情况是否需要任何系统更改、重新配置等。
顺便说一句,我非常喜欢捕捉一切,然后过滤信息。
如果您在“警告”级别捕获,并希望获得与警告相关的一些调试信息,但无法重新创建警告,会发生什么情况?
捕获所有内容并稍后过滤!
即使对于嵌入式软件,这也是正确的,除非你发现你的处理器跟不上,在这种情况下,你可能需要重新设计你的跟踪以使其更高效,或者跟踪干扰了时间(你可能会考虑在一个更强大的处理器上调试,但这会带来另一种蠕虫)。
捕获所有内容并稍后过滤!!
(顺便说一句,捕获一切也很好,因为它让您可以开发工具来做更多的工作,而不仅仅是显示调试跟踪(我从中绘制了消息序列图,以及内存使用情况的直方图。它还为您提供了一个基础,以便在将来发生错误时进行比较(保留所有日志,无论是通过还是失败,并确保在日志文件中包含内部版本号))。
如果你能从问题中恢复过来,那就是一个警告。如果它阻止了继续执行,那就是一个错误。
我一直在考虑警告第一个日志级别,这肯定意味着存在问题(例如,可能配置文件不在应该的位置,我们将不得不使用默认设置运行)。对我来说,一个错误意味着软件的主要目标现在不可能实现,我们将尝试彻底关闭。
正如其他人所说,错误是问题;警告是潜在的问题。
在开发中,我经常使用警告,在警告中,我可能会放置相当于断言失败,但应用程序可以继续工作;这使我能够发现这个案子是否真的发生过,或者这是我的想象。
但是的,它归结到恢复性和现实性方面。如果你能恢复,那可能是一个警告;如果它导致某个东西实际失败,那就是一个错误。