一些朋友刚刚完成了一个应用的实现，他们使用了自定义异常。引起我注意的是，当引发自定义异常时，他们将异常记录在他们实现的异常基类的代码中。所以我的问题是这是一个好的设计方法吗？我的想法是日志助手更有用
public class BaseCustomException: System.Exception
{
public BaseCustomException()
{
TightlyCoupledClass.Log(this);
}
}
【问题讨论】：
标签： .net exception-handling exception-logging
不，这是一种可怕的 IMO 方法。原因是假设每个创建的异常都会被抛出，但事实并非如此。
由于异常通常是只读的，因此在某些实现中，将为特定情况创建一个异常，并在必要时重新引发（CLR 在引发异常时设置 StackTrace，而不是在构造时设置）。
底线，这并不常见，但有可能在创建时不会抛出异常，您不应该基于此做出假设。
【讨论】：
我理解他们将其落实到位的想法，以便他们可以确保在引发 CustomException 异常时进行日志记录；但是，这绝对是臭代码。
异常应该仅用于异常，执行可能导致引发 CustomException 的代码的代码应该能够决定如何处理该异常以及是否记录它...因为日志记录应该特定于它所引起的场景。
附带说明，自定义异常应作为根从 ApplicationException 继承，以便您可以判断该异常是自定义的业务库还是来自 .NET 框架本身。
--CORRECTION-- 我刚刚发现this post，我不知道它本质上使用 ApplicationException 渲染是无用的。
【讨论】：
我不这么认为。我会设置一个全局异常处理程序，它将异常（和其他数据）写入日志。这样你只写捕获的异常。
【讨论】：
此解决方案耦合过于紧密，无法配置。我建议使用更强大的异常处理框架，例如Enterprise Library Exception Handling Application Block。
【讨论】：
在构造函数中记录是很讨厌的。尝试操作的代码应该如何构造可能包含异常的有意义的消息？异常的作用是代表问题，而不是记录消息。其他一些代码应该注意这一点，以便可以捕获该特定异常的每个部分都可以按照他们的意愿行事，这可能涉及也可能不涉及记录异常。
对于构造函数中的日志，如果异常被包装并重新抛出以再次捕获，则异常将被记录两次，这是愚蠢的。
catch ( CustomException exception ){
Logger.error( "Really useful message", exception );
}
【讨论】：