【发布时间】：2011-08-05 05:17:42
【问题描述】：
我在一个项目中，团队定义了一个自定义异常类型，在其构造函数中调用了一个 Logging 方法，该方法记录了传递给构造函数的异常。
我会认为这很糟糕 - 是吗？
问题是，虽然我可以删除“自我日志记录”，但我不知道有多少人依赖那里的日志记录。
【问题讨论】：
标签： .net logging exception-handling error-handling custom-exceptions
【发布时间】：2011-08-05 05:17:42
【问题描述】：
C++ 社区一直在争论在构造过程中处理异常的正确方法。问题是，如果你在构造函数中抛出一些东西，这应该意味着你无法构造对象。相反，如果代码只是注意到事情不是最理想的，但施工仍在继续，那应该以其他方式完成。这将调用Don't Use Exceptions for Flow of Control 反模式。
【讨论】：
-
很好 - 我喜欢对反模式的引用。
我会说这可能很糟糕。它让我想起了我读到的一些代码，这是一位同事不久前写的——在一个公共辅助方法中，他们没有抛出异常，而是执行了带有错误消息的 MessageBox.Show()。这很糟糕有几个原因，其中之一是我想使用该方法而不向用户显示愚蠢的错误。
就个人而言，我喜欢控制方法是否记录信息（大部分情况下）。如果我想以一种不会弄乱我的日志文件的方式处理异常怎么办？
另一方面，也许编写代码的人故意这样设计它，以确保其他程序员不会在他们应该记录的时候侥幸逃脱。这取决于场景。
我个人不喜欢它，因为它是关注点分离问题 - 日志记录可能应该与方法尝试执行的任务分离。除非日志记录是该任务的重要组成部分。对于某些例外情况，日志记录可能非常重要。
【讨论】：
-
我同意 Phil 的观点，另外我可能会提到 Microsoft 企业库仅通过 XML 配置提供日志记录功能。另外，当与异常应用程序块结合使用时，EntLib 允许指定应记录或不应记录哪种类型的异常。
我认为这很糟糕。为什么不使用未处理的异常事件处理程序来捕获它们并在那里进行正确的日志记录？您描述它的方式违反了单一责任原则 (SRP)，并且还记住异常是可序列化的，例如，如果您在服务上下文（例如 WCF 服务）中生成异常，然后将其传输到您的客户端（Web /desktop 应用程序）应该在哪里进行日志记录？像这样的问题/问题告诉我最好将日志记录与异常分开并将它们分开。
【讨论】：
-
我完全同意你（和菲尔）关于 SRP 的看法。关于可序列化异常的良好调用。