.net - 在 Exceptions 基类的代码上记录异常是一种好的设计方法吗？

Question

一些朋友刚刚完成了一个应用程序的实现，他们使用了自定义异常。引起我注意的是，当引发自定义异常时，他们将异常记录在他们实现的异常基类的代码中。所以我的问题是这是一个好的设计方法吗？我的想法是日志助手更有用

 public class BaseCustomException: System.Exception
{

   public BaseCustomException()
   {
              TightlyCoupledClass.Log(this);
   }

}

score 3 · Accepted Answer

不，这是一种可怕的方法 IMO。原因是假设创建的每个异常都会被抛出，但事实并非如此。

由于异常通常是只读的，因此在某些实现中，将为特定情况创建一个异常，并在必要时重新引发（CLR 在引发异常时设置 StackTrace，而不是在构造时设置）。

最重要的是，这并不常见，但创建时可能不会抛出异常，您不应该基于此做出假设。

score 2 · Accepted Answer

我理解他们将其落实到位的想法，以便他们可以确保在引发 CustomException 异常时进行日志记录；但是，这绝对是臭代码。

异常应该仅用于异常，并且执行可能导致引发 CustomException 的代码的代码应该能够决定如何处理该异常以及是否记录它......因为日志记录应该是特定的到导致它的场景。

附带说明，自定义异常应该从 ApplicationException 作为根继承，以便您可以判断异常是自定义的业务库还是来自 .NET 框架本身。
--更正-- 我刚刚发现这篇我不知道的帖子本质上使用 ApplicationException 渲染是无用的。

score 0 · Accepted Answer

我不这么认为。我会设置一个全局异常处理程序，它将异常（和其他数据）写入日志。这样你只写捕获的异常。

score 0 · Accepted Answer

在构造函数中记录是非常讨厌的。尝试操作的代码应该如何构造可能包含异常的有意义的消息？异常的作用是代表问题，而不是记录消息。其他一些代码应该注意这一点，以便可以捕获该特定异常的每个部分都可以做他们想做的事情，这可能涉及也可能不涉及记录异常。

对于构造函数中的日志，如果异常被包装并重新抛出以再次捕获，则异常将被记录两次，这是愚蠢的。

catch ( CustomException exception ){
Logger.error( "Really useful message", exception );
}

score 0 · Accepted Answer

这个解决方案耦合太紧，而且不可配置。我建议使用更健壮的异常处理框架，例如Enterprise Library Exception Handling Application Block。

5 回答 5