记录代码应该在哪里/哪个级别？

Question

我想知道日志记录代码应该去哪里。例如，我的存储库是否应该记录它自己的错误？或者我应该从UI /控制器记录所有错误？是否有任何关于此的一般设计原则，或者是否有人链接到好文章或某些东西。

Answer 1

Answer 2

通常，最好在您拥有所有必要信息的地方记录事物。为了使您的应用程序更简单，最好不要传递数据，以便您可以将其记录到其他地方。 （异常似乎是一个例外 - 对于双关语:-)抱歉 - 但它们的主要目的不是记录，这只是一个可能的副作用。）

没有必要将日志记录限制到体系结构的特定模块/层（除了一些特殊情况，例如不应该记录任何内容的设备驱动程序，或者不能对环境做出假设的应用程序库）。 / p>

请注意，即使在同一个应用程序中，不同的日志消息也可能有不同的用途：

• 提供有关应用程序中（正常）事件流的信息（即批处理应用程序可以记录它开始和结束，可能是处理的简要结果等）。这些消息最好相对较少，包含有限数量的信息，因为它们通常意味着人类阅读（例如系统管理员在早上检查应用程序成功运行）。由于这些是“正常”消息，因此它们的优先级位于比例的中间，例如， INFO。
• 警告异常事件（例如错误，崩溃，丢失文件......）。这些消息应该很少（在普通应用程序中），但可能包含过多的信息（例如堆栈跟踪，核心转储等），这可能有助于识别底层错误。但是，当它们发生时，我们几乎总是希望看到它们，因此它们具有高优先级，例如ERROR或FATAL。
• 提供有关应用程序特定部分内容的详细信息（通常用于调试目的）。这些消息通常是真正的生猪，通常会生成千兆字节的日志数据。因此，我们只想在特定情况下看到它们，因此很容易将它们的水平设置为低，例如DEBUG。

现代日志记录框架（如Log4J系列）允许非常灵活地处理来自应用程序不同部分的不同类型（级别）的消息。但是，在向代码添加大量日志消息之前，最好规划您的日志记录方案。即您计划在哪些类型的消息中记录应用程序的哪些部分，以及您将如何使用这些消息？您需要多少个什么样的日志目标（控制台，文件，数据库）？

Answer 3

我发现微软架构指南很好。 http://msdn.microsoft.com/en-us/library/ff650706.aspx

记录是所有图层的一个贯穿各领域的关注点

Answer 4

到目前为止，我已经使用了“黑匣子”策略。每一段代码（函数或/和类）在很多方面都有自己的责任：输入测试，执行它的意图，错误处理，记录信息。因此，如果您的代码片段位于业务层中，它应该抛出业务方面的错误，以及记录业务方面的信息

Answer 5

我认为常见的错误处理在应用程序中非常重要。

从JavaWorld开始，以下是原因，为什么常见的错误处理至关重要：

1. 肿胀日志：每个catch块都包含一条日志语句，导致由污染源代码导致的膨胀和冗余日志条目。

2. 冗余实现：相同类型的错误具有不同的表示形式，这使得处理方式变得复杂。

3. 破解封装：其他组件的异常被声明为方法签名的一部分，打破了界面与实现之间的明确划分。

4. 非明确异常声明：方法签名被推广为抛出java.lang.Exception。这样，确保客户端不会对方法的错误语义有任何线索。