自定义异常类型为“自记录”-不好吗?

| 我在一个团队定义了自定义异常类型的项目中,该异常类型的构造函数是对Logging方法的调用,该方法记录传递给构造函数的异常。 我本以为这很不好-是吗? 问题是,尽管我可以删除“自我记录”,但我不知道有多少人依赖那里的记录。     
已邀请:
我会说这可能很糟糕。这让我想起了我读到的某位同事在一段时间以前写的一些代码-在公共帮助器方法中,他们没有抛出异常,而是执行了带错误消息的MessageBox.Show()。这是非常糟糕的,原因有几个,其中之一就是我想使用该方法而不向用户显示愚蠢的错误。 就个人而言,我喜欢控制方法是否记录信息(大部分情况下)。如果我想以一种不会使我的日志文件混乱的方式处理该异常怎么办? 另一方面,也许编写代码的人故意以此方式设计了代码,以确保其他程序员不会在应有的情况下逃避NOT记录。这取决于场景。 我个人不喜欢它,因为这是一个关注点分离问题-日志记录可能应该与该方法尝试执行的任务分离。除非日志记录是该任务的必要部分。对于某些例外情况,日志记录可能非常重要。     
C ++社区争论了在构造过程中永远处理异常的正确方法。问题在于,如果您在构造函数中抛出了某些内容,则意味着您无法构造该对象。如果不是这样,代码只是指出事情不是最理想的,而是继续进行构建,那应该以其他方式完成。这将调用“控制流不使用异常”反模式。     
我认为这很糟糕。为什么不使用未处理的异常事件处理程序来捕获所有异常并在那里进行正确的日志记录?描述它的方式违反了单一职责原则(SRP),并且还请记住,异常是可序列化的,因此例如,如果您在服务上下文(例如WCF服务)中生成异常,然后将其传输到客户端(Web / desktop应用程序)应该在哪里记录日志?这样的问题/问题告诉我,最好将日志记录与异常分开,并使其分开。     

要回复问题请先登录注册