.net - 自定义异常类型是“自我记录”——这很糟糕吗？

Question

我在一个项目中，团队定义了一个自定义异常类型，在其构造函数中调用了一个 Logging 方法，该方法记录了传递给构造函数的异常。

我会认为这很糟糕 - 是吗？

问题是，虽然我可以删除“自我记录”，但我不知道有多少人依赖那里的日志记录。

Answer 1

C++ 社区一直在争论在构造过程中处理异常的正确方法。问题是，如果你在构造函数中抛出一些东西，这应该意味着你无法构造对象。相反，如果代码只是注意到事情不是最理想的，但施工仍在继续，那应该以其他方式完成。这将调用Don't Use Exceptions for Flow of Control反模式。

Answer 2

我会说这可能很糟糕。它让我想起了我读到的一些代码，这是一位同事不久前写的——在一个公共辅助方法中，他们没有抛出异常，而是执行了带有错误消息的 MessageBox.Show()。这很糟糕，原因有几个，其中之一是我想使用该方法而不向用户显示愚蠢的错误。

就个人而言，我喜欢控制方法是否记录信息（大部分情况下）。如果我想以一种不会弄乱我的日志文件的方式处理异常怎么办？

另一方面，也许编写代码的人故意这样设计它，以确保其他程序员不会在他们应该记录的时候侥幸逃脱。这取决于场景。

我个人不喜欢它，因为它是关注点分离问题 - 日志记录可能应该与方法尝试执行的任务分离。除非日志记录是该任务的重要组成部分。对于某些例外情况，日志记录可能非常重要。

Answer 3

我认为这很糟糕。为什么不使用未处理的异常事件处理程序来捕获它们并在那里进行正确的日志记录？您描述它的方式违反了单一责任原则 (SRP)，并且还记住异常是可序列化的，例如，如果您在服务上下文（例如 WCF 服务）中生成异常，然后将其传输到您的客户端（Web /desktop 应用程序）应该在哪里进行日志记录？像这样的问题/问题告诉我最好将日志记录与异常分开并将它们分开。