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

Question

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

我想到了4个级别：

0：没有调试 1：所有输入和输出 2：“我在这里”来自具有主要参数的重要功能的通知 3：所有变量都很冗长

Answer 1

这是我们在一个项目中所做的工作。它不是记录级别的圣经，只是一种可能性。记录应适合您的情况。

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

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

Answer 2

我通常使用的不仅仅是四个级别，尽管它们不一定有名字。您可以查看'syslog'守护进程提供的级别。

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

（log4j包添加了一个低于'debug'的级别，称为'Trace'，但只提供'Fatal'，其中syslog和syslogd提供紧急，警报和严重。）这些并不直接相关，但应该给你一些思考。 Pax提供的清单非常合理。

我经常发现有用的一件事是分段调试 - 可以为系统的不同组件设置不同级别的调试。例如，根据故障的位置，我可能需要在输入部分和宏管理部分进行大量调试，而不需要在主处理代码中进行任何调试。整个程序的单个调试级别比没有好，但对于复杂的程序，区分是非常宝贵的。

您可以在我的SOQ（Stack Overflow Questions）存储库中找到我在GitHub上使用的源代码，作为debug.h子目录中的文件debug.c，mddebug.c，src/libsoq。

Answer 3

我有：

• 严重/致命，程序无法继续，通常用户丢失它。
• 错误，有些错误，使用数据可能会损坏，但你可以幸运。
• 警告，这不对，我可以继续，但请看看。
• 提示/信息，我想说点什么，但我不指望你听。
• 调试，所有信息只对程序员有意义。

Normaly最低的两个级别被阻止。但显示其他人。如果你想阻止致命等级，对我很好，但不要指望我事后清理乱七八糟（不幸的是我仍然要......）。

Answer 4

无论你选择什么，都会有你想看到的东西，只是进入下一个层次......

我不认为这个问题有一个通用的答案，因为它依赖于应用程序正在做什么。就像Haynes手册中的油页一样（英国读者会知道我的意思），我倾向于发现你在传统上很麻烦的地方最终会进行大量伐木，而且这个地区几乎没有你接下来麻烦了。

Answer 5

这是我的清单：

• 静音模式：

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

• 错误方式：

将严重和不可恢复的错误记录到控制台。

• 警告模式：

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

此模式不是为了捕获错误，而是为使用我的应用程序/库的其他程序员提供信息。在警告模式中，我主要检查输入参数并尝试检测是否有人试图做一些愚蠢的事情。像蛮力一个解决方案或只传递最慢的数据类型。

• 调试模式（1-4级）

在调试模式下，我开始记录所有内容，按出现频率排序。一级不是很冗长。记录了我的程序/应用程序所做的主要事情。不多了。此模式旨在用于粗略了解客户端正在执行的操作。

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

我的最高级别的调试保留用于所有进程间和线程间通信。所有对信号量，互斥锁等的访问都将尽可能详细地记录。

Answer 6

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

我已经看到了开发人员在无法传递数据包时记录错误的示例，即使已经处理并且调用者已完成重新发送。 有问题的开发人员说：“但在这种情况下，这是一个错误”。

您需要定义以下内容： 错误表示应用程序已失败，需要重新启动。 警告可能会显示应用程序的单个功能已失败，但应用程序可以恢复并继续 等等...

确切的级别数与整个应用程序中这些级别的一致使用并不重要。

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

Answer 7

我缩进了将调试日志与审计日志和异常日志分开。因此，例如成功完成或未成功的函数SendMessage的信息日志将是审计日志，但是发送导致异常的消息的应用程序的任何失败日志都将是异常日志。

调试日志仅用于调试目的。这个级别让我选择调试的严重程度。

我认为对于在组中工作的开发人员来说，在开始编码之前设置这些规则很重要。所以日志记录将包含在内。

谢谢你的好建议！

暗利。

Answer 8

0：没有记录

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

2：操作日志记录：日志操作（不在catch块（正常操作）中）应设置为高调试。这样，您可以看到哪个方法开始执行，然后在catch块中结束。

另外，考虑记录交换机，例如数据包记录（true：记录网络数据包/消息，false：不记录）。只是不要过度使用开关。

在异常处理时，每个方法体至少应该在try-catch块中，至少在最后使用一般的Exception catch。将日志记录放入catch块，添加除系统消息和堆栈跟踪之外的可选信息以指示导致错误的原因，然后抛出错误。只有当用户收到有关错误的通知，或者您处于没有活动用户界面的应用程序的顶层时，才能进一步停止抛出错误。 （例如，服务器端日志记录。）然后，您需要在客户端应用程序的消息中指出服务器端发生了错误。