TraceListener，它在失败的断言上抛出异常。

Question

DefaultTraceListener (它是唯一的跟踪侦听器，如果不是在app.config中重写)的问题是，如果AssertUiEnabled是false (即在ASP.NET中)，它会在失败的断言(对Trace.Assert(false)的调用)上以OutputDebugString的形式写入消息，但是继续执行。

所以我使用了下面的TraceListener子类，它会抛出一个异常。我用

TraceListenerWhichThrowsExceptionOnFail.InsertAsFirstTraceListener(Trace.Listeners);

在Application_Init中。

现在，在Application_Error事件中，我可以用完整的堆栈跟踪记录异常(作为任何异常)，包括调用Trace.Assert(false)。

public class TraceListenerWhichThrowsExceptionOnFail : TraceListener
{
    public static void InsertAsFirstTraceListener(TraceListenerCollection traceListeners)
    {
        traceListeners.Insert(0, new TraceListenerWhichThrowsExceptionOnFail());
    }

    public override void Fail(string message, string detailMessage)
    {
        message = string.IsNullOrEmpty(detailMessage) ? message : message + ", Detail message: " + detailMessage;

        throw new ApplicationException("Trace assertion failed" + 
            (string.IsNullOrEmpty(message) ? "" : ": " + message) + ".");
    }

     public override void Write(string message)
     {
        // NOP
     }

     public override void WriteLine(string message)
     {
        // NOP
     }
}

现在我的问题是:有人认为这种方法有问题吗？

Answer 1

我认为Trace.Assert中的异常是个坏主意(不看代码)。

通常用于跟踪内容的Trace.XXXX方法。对于未来的读者(包括您)来说，知道Trace.Assert实际上抛出异常是非常令人惊讶的。

看到Trace.Assert (甚至失败)抛出异常更加令人惊讶。断言的目的是帮助预先识别问题，而不是扼杀应用程序。

我建议您的自定义方法在名称中清楚地显示其行为，而不是出现现有方法的意外行为。

Answer 2

在Fail()中抛出异常可能导致: 1.调用堆栈将引起混淆，因为异常不会在条件失败的附近抛出。

通常，您应该在条件失败的地方抛出异常。