关于c＃：安全处理异常时避免出现第一次机会异常消息

Avoiding first chance exception messages when the exception is safely handled

以下代码捕获EOS异常

1
2
3
4
5
6
7
8

using (var reader = new BinaryReader(httpRequestBodyStream)) {

try {
while (true) {
bodyByteList.Add(reader.ReadByte());
}
} catch (EndOfStreamException) { }
}

那么，为什么我的控制台中仍然会出现首次机会异常？

A first chance exception of type 'System.IO.EndOfStreamException' occurred in mscorlib.dll

有没有办法隐藏这些第一次机会异常消息？

为了避免看到消息，请右键单击输出窗口，然后取消选中"异常消息"。

但是，如果您想知道何时在不设置断点和重新配置调试器的情况下引发异常，那么看到它们的发生可能会很好。

"优先机会"异常的要点是您看到它们是预处理程序，因此您可以在调试时在抛出时停止它们。"第二次机会"异常是没有适当处理程序的异常。有时您想捕获"优先机会"异常，因为重要的是要观察抛出异常时发生的情况，即使有人正在捕获它。

没什么可担心的。这是正常现象。

1)在Visual Studio中，您可以更改调试器处理(中断)异常的方式的设置。

转到调试>异常。 (请注意，根据您的Visual Studio环境设置，此菜单可能不在菜单中。如果不是，请使用"自定义"菜单将其添加到菜单中。)

在该对话框中，您会看到一个对话框，讨论异常以及何时中断它们。

在"公共语言运行时异常"行中，您可以取消选择抛出(这将使您不再为第一次机会异常而烦恼)，并且如果需要，还可以取消选择用户未处理的(我不建议这样做)。

2)您收到的消息不应在控制台中，而应出现在Visual Studio的"输出"窗口中。如果是后者，那么我还没有找到删除它的可能，但是如果您在没有Visual Studio的情况下运行该应用程序，则不会出现。

希望能有所帮助。

与Java不同，.NET异常在处理能力方面非常昂贵，在正常且成功的执行路径中应避免处理异常。

您不仅可以避免在控制台窗口中造成混乱，而且可以提高性能，并使诸如.NET CLR Exceptions之类的性能计数器更有意义。

在此示例中，您将使用

1
2
3
4

while (reader.PeekChar() != -1)
{
bodyByteList.Add(reader.ReadByte());
}

我遇到了这个问题，无法弄清楚在哪里抛出异常。因此，我的解决方案是使Visual Studio停止执行此类异常。

导航到"调试/异常"

展开"公共语言运行时异常"树。

展开"系统"分支。

向下滚动到" NullReferenceException"所在的位置，然后检查
"抛出"复选框，然后取消选中"用户处理"。

调试您的项目。

如果要进一步控制这些消息，可以添加一个处理程序：

1
2
3
4
5
6
7
8
9

Friend Sub AddTheHandler()
AddHandler AppDomain.CurrentDomain.FirstChanceException, AddressOf FirstChanceExceptionHandler
End Sub

<Conditional("DEBUG")>
Friend Sub FirstChanceExceptionHandler( source As Object, e As Runtime.ExceptionServices.FirstChanceExceptionEventArgs)
' Process first chance exception

End Sub

如其他注释中所述，这使您可以使它们静音，但仍可确保您能够意识到它们。我发现如果将消息和时间戳记记录到文本文件中，可以看到实际抛出了多少个消息。

实际上，如果每秒有多个异常，则可以通过检查reader.EndOfStream-value来实现更好的性能。打印出这些异常消息的速度令人难以置信，并且将它们隐藏在Visual Studio中不会加快任何速度。

在VB.NET中：

1
2
3

<DebuggerHidden()> _
Public Function Write(ByVal Text As String) As Boolean
...

我认为该流将引发此异常，因此您可以尝试缩小范围以捕获它。

在不同的作用域周围再添加一些try catch组合，直到将其实际抛出的地方捕获为止，但是它似乎是在您使用的外部发生的，因为stream对象不是在using的作用域中创建的。