自定义异常类型是“自我记录” - 这是不是很糟糕?

时间:2011-04-14 03:37:11

标签: .net logging exception-handling error-handling custom-exceptions

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

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

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

3 个答案:

答案 0 :(得分:1)

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

答案 1 :(得分:1)

我想说这可能不好。它让我想起了我刚读过的一些代码 - 一个同事在一个公共帮助器方法中,而不是抛出异常,他们做了一个带有错误消息的MessageBox.Show()。这有几个原因非常糟糕,其中一个原因是我想使用该方法而不向用户显示愚蠢的错误。

就个人而言,我喜欢控制方法是否记录信息(大多数情况下)。如果我想以不会弄乱我的日志文件的方式处理异常怎么办?

另一方面,编写代码的人可能是故意这样设计的,以确保其他程序员不应该在他们应该的时候记录。这取决于场景。

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

答案 2 :(得分:0)

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