Avoiding first chance exception messages when the exception is safely handled

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?

To avoid seeing the messages, right-click on the output window and uncheck "Exception Messages".

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

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.

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.

Unlike Java, .NET 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());
}

I had this problem and couldn't figure out where the exception was thrown. So my solution was to enable Visual Studio to stop executing on this kind of exception.

1. Navigate to "Debug/Exceptions"
2. Expand the "Common Language Runtime Exceptions" tree.
3. Expand the "System" branch.
4. Scroll down to where "NullReferenceException" is, and check the "throw" checkbox, and uncheck the "user-handled".
5. Debug your project.