Avoiding first chance exception messages when the exception is safely handled

Question

The following bit of code catches the EOS Exception

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

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

So why do I still receive first-chance exceptions in my console?

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

Is there a way to hide these first chance exception messages?

Answer 1

I think the stream is throwing this exception, so your try is scoped to narrow to catch it.

Add a few more try catch combos around the different scopes until you catch it where its actually being thrown, but it appears to be happening either at our outside of your using, since the stream object is not created in the using's scope.

Answer 2

The point of "first-chance" exceptions is that you're seeing them pre-handler so that you can stop on them during debugging at the point of throwing. A "second-chance" exception is one that has no appropriate handler. Sometimes you want to catch "first-chance" exceptions because it's important to see what's happening when it's being thrown, even if someone is catching it.

There's nothing to be concerned with. This is normal behavior.

Answer 3

1) In Visual Studio you can change the settings for the way the Debugger handles (breaks on) exceptions.

Go to Debug > Exceptions. (Note this may not be in your menu depending on your Visual Studio Environment setting. If not just add it to your menu using the Customize menu.)

There you are presented with a dialog of exceptions and when to break on them.

In the line "Common Language Runtime Exceptions" you can deselect thrown (which should then stop bothering you about first-chance exceptions) and you can also deselect User-unhandeled (which I would not recommend) if want to.

2) The message you are getting should not be in the console, but should be appearing in the 'Output' window of Visual Studio. If the latter is the case, then I have not found a possibility to remove that, but it doesn't appear if you run the app without Visual Studio.

Hope that helps.

Answer 4

Unlike Java, Dotnet exceptions are fairly expensive in terms of processing power and handled exceptions should be avoided in the normal and successful execution path. Not only will you avoid clutter in the console window but your performance will improve and it will make performance counters like .NET CLR Exceptions more meaningful.

In this example you would use

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

Answer 5

To avoid seeing the messages, right-click on the output window and uncheck "Show exceptions" (the name may not be exactly that, I don't have VS here right now).

However, seeing them happen might be nice, if you're interested in knowing when exceptions are thrown without setting breakpoints and reconfiguring the debugger.

Answer 6

ChanChan ever heard of the stacktrace in a exception? :P that will be atleast 100% faster to use if you want to know where its thrown but i dont think thats the problem here....

Answer 7

in VB.Net...

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

Answer 8

Actually if are having many exceptions per second, you would achieve must better performance by checking reader.EndOfStream-value.. Printing out those exception messages is unbelievably slow, and hiding them in visual studio won't speed up anything.