2

我的问题DefaultTraceListener（这是唯一的跟踪侦听器，如果在 app.config 中没有被覆盖）是，如果AssertUiEnabled是false（即在 ASP.NET 中）它会OutputDebugString在失败的断言（调用）时写入一条消息Trace.Assert(false)，但会继续执行。

所以我正在使用以下子类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
     }
}

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

4

3 回答 3

0

这取决于。

我不确定这在 ASP.NET 场景中是否有用。在调试期间，您希望断言正常运行。抛出异常可能会有点混乱。在生产中，您将使用发布版本，因此这些Trace.Assert语句无论如何都不会做任何事情。

但是，我们使用类似的技术进行单元测试。您真的不想让构建服务器挂起并显示“断言失败”消息框。相反，您希望您的断言导致测试失败。因此，我们使用 App.config 文件进行单元测试（并且仅用于软管！），它安装了一个与您的类似的跟踪侦听器。

于 2013-02-28T23:08:38.367 回答
0

我会说 Trace.Assert 中的异常是个坏主意（不查看您的代码）。

Trace.XXXX 方法通常用于跟踪内容。将来的读者（包括您）得知Trace.Assert实际上会引发异常，这将是非常令人惊讶的。

看到 Trace.Assert（甚至是 Fail）抛出异常更令人惊讶。Assert 的目的是帮助提前发现问题，而不是杀死应用程序。

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

于 2013-02-28T22:53:56.773 回答
-1

在 Fail() 中抛出异常可能会导致： 1. 调用堆栈会令人困惑，因为异常不会在条件失败的地方抛出。

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

于 2013-03-02T07:30:41.347 回答