Debugging 编写应用程序时的调试级别

我想知道你们在编写应用程序时是否对调试级别有任何建议

我想到了4个层次：

0:无调试
1：所有输入和输出
2：“我在这里”来自具有主要参数的重要功能的通知

---

3：所有变量都是冗长的

无论您选择什么，都会有一些您想要看到的东西，它刚刚进入下一个级别

我不认为这个问题有一个通用的答案，因为它是如此依赖于应用程序正在做什么。就像《海恩斯手册》中油腻的页面一样（英国读者会知道我的意思），我倾向于发现，在传统上很麻烦的领域，你最终会遇到大量的日志记录，而在接下来会给你带来麻烦的领域，几乎没有任何日志记录。

以下是我的列表：

• 静默模式：

应用程序不会发出任何与调试相关的消息。在任何情况下，应用程序都不会向UART或调试控制台发出任何信息

• 错误模式：

硬错误和不可恢复错误将记录到控制台

• 警告模式：

启用旨在帮助其他程序员的额外调试信息

此模式的目的不是捕获bug，而是向使用我的应用程序/库的其他程序员提供信息。在警告模式下，我主要检查输入参数，并尝试检测是否有人试图做傻事。就像蛮力解决方案或只传递最慢的数据类型一样

• 调试模式（1-4级）

在调试模式下，我开始记录所有事情，按发生频率排序。第一级不是很冗长。我的程序/应用程序所做的主要事情都会被记录下来。不多了。此模式用于大致了解客户在做什么

调试模式越高，记录的信息越多

---

我的最高调试级别是为所有进程间和线程间通信保留的。所有对信号量、互斥量等的访问都将被尽可能详细地记录下来。

以下是我们在我参与的一个项目中所做的。这不是日志记录级别的圣经，只是一种可能性。日志记录应适合您的情况

• 记录需要退出程序的严重错误（例如，在应用程序中，磁盘空间不足）
• LOG_ERROR，无法从中恢复但程序可以继续运行的错误消息（例如，在服务器应用程序中，客户端通过坏数据发送，但其他客户端可以继续运行）
• LOG_警告，应通知您的可恢复问题（例如，配置文件中的值无效，因此您返回默认值）
• 日志信息、信息性消息
• 所有功能的日志输入、日志输入和退出
• LOG_PARM，记录所有传递参数和返回值的函数的输入和输出（包括全局效果，如果有）
• 日志调试，一般调试消息，基本有用的信息，可以在一行上输出
• LOG_HIDEBUG，更详细的调试消息，如缓冲区的十六进制转储

---

每个级别还以“较低”级别记录消息。有时会出现一个问题，即调试消息应该是LOG_debug还是LOG_HIDEBUG，但我们主要基于它将推送到日志文件的行数。

对于不同级别的日志记录，最重要的是所有开发人员都使用相同的定义

我见过开发人员在无法交付数据包时记录tcp数据包错误的例子，即使该数据包已被处理，并且由调用者重新发送。
有问题的开发者说：“但在这种情况下，这是一个错误”

您需要定义如下内容：

---

错误表示应用程序失败，需要重新启动。
可能会出现一个警告，说明应用程序的单个功能已失败，但应用程序可以恢复并继续运行
等等

级别的确切数量不如在整个应用程序中一致使用这些级别那么重要

---

如果可以在运行时更改级别，并在可能的情况下为应用程序的不同部分选择不同的级别，这将非常有用。

我缩进以将调试日志与审核日志和异常日志分开。因此，具有信息性的日志（例如，函数SendMessage是否成功完成）将成为审核日志，但导致异常的应用程序发送该消息失败的日志将成为异常日志

调试日志仅用于调试目的。级别由我来选择调试的严重程度

我认为对于在团队中工作的开发人员来说，在开始编写代码之前设置这些规则是很重要的。。因此，日志记录将包括

谢谢你的好建议

Omri.

我有：

• 严重/致命，程序无法继续，通常用户会丢失它
• 错误，一些真正的错误，使用过的数据可能会被破坏，但你可以幸运
• 警告，这不对，我可以继续，但请看一看
• 提示/信息，我想说点什么，但我不希望你听
• 调试，所有信息只对程序员感兴趣

通常情况下，最低的两个级别被阻止。但其他的都显示出来了。如果你想阻止致命级别，我没问题，但不要指望我会在事后收拾残局（不幸的是，我仍然必须……。

0:没有日志记录

1：异常日志记录：记录每个抛出的错误。例如在c#中：登录catch块。触发这些日志操作时，您就知道有错误。如果存在不应被击中的情况等，也可以登录switch语句

2：操作日志记录：记录操作，其中

0 - Emergency (emerg)
1 - Alerts (alert)
2 - Critical (crit)
3 - Errors (err)
4 - Warnings (warn)
5 - Notification (notice)
6 - Information (info)
7 - Debug (debug)