.net - 调试 Windows 服务，添加数据库日志记录来捕捉线索是个坏主意？

Question

我有一个正在尝试调试的 Windows 服务。

在 Catch() 子句中添加错误日志记录是个坏主意吗？

我的日志记录是使用数据库来记录错误。

score 3 · Accepted Answer

当您提到调试和日志记录时，我不是 100% 清楚您正在尝试做什么。

如果作为整体日志记录方法的一部分，在 catch 子句上进行日志记录通常是一个好主意。

如果您在调试服务之后，您有两个选择 - 如果您可以控制尝试从服务外部调试的代码（通过一些外部刺激），或者如果您在执行代码之前有一段时间，您可以简单地打开VS 中的源代码，并且只要您在调试模式下编译，您就可以将 VS 附加到服务进程。

然后在您的源代码中设置的任何断点都可以让您访问调试中的代码。

但是，如果您不能这样做（例如，如果您需要调试启动事件），您可以将 System.Diagnostics.Debugger.Break() 添加到源代码中，这将在运行时命中此行时启动调试器.

我通常通过编译符号将此类语句包装在#if #endif 区域控件中。

score 2 · Accepted Answer

在我负责的服务中，初始化后发生的任何错误（在代码确认它可以连接到数据库、可以访问日志文件并开始工作之后）都会被放入其日志文件中。启动或关闭时发生的错误会发送到事件日志。

score 2 · Accepted Answer

一般来说，记录异常是个好主意。尤其是在调试服务时，这总是一项令人讨厌的任务。

您可能遇到的唯一问题是日志记录本身会导致异常。当我登录到事件日志时，这发生在我身上（有关详细信息，请参阅此问题）。这意味着您无法获得有关导致服务失败的异常的信息。

出于调试目的，我认为将异常记录到本地文本文件中很有用，除了您执行的任何其他日志记录。这是最不可能失败的。完成调试后，您可以删除那些额外的日志记录命令。（好吧，你必须小心不要在这样做时引入新的错误......）

score 1 · Accepted Answer

这取决于代码。在我的一些服务中，我将信息记录到数据库中（因为这是这里的策略），但是我有一个辅助记录机制，可以在记录到数据库失败的情况下将消息添加到事件日志中。您必须问自己的问题是“如果无法连接到数据库，错误会发生什么？”

4 回答 4