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?

André Chalella · Answer 1 · 2014-01-17T16:30:52.083

190

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.

edited Jan 17 '14 at 16:30

answered Sep 13 '08 at 18:48

André Chalella

13,788
10
54
62

score 79 · Accepted Answer · answered Sep 12 '08 at 05:56

79

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.

answered Sep 12 '08 at 05:56

Brad Wilson

67,914
9
74
83

58

Indeed, it is nothing to be concerned with, but they do clutter up the debug output log :( – Dimitri C. Apr 28 '10 at 12:50

score 20 · Answer 3 · edited Apr 23 '21 at 08:45

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.
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.

score 12 · Answer 4 · edited Apr 26 '15 at 16:29

12

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());
}

edited Apr 26 '15 at 16:29

Peter Mortensen

30,738
21
105
131

answered Sep 12 '08 at 06:32

loudej

1,889
11
17

1

or you could get all the bytes in one shot with ReadBytes and also make use of buffering. but I guess that wasn't the question. – Craig Tyler Sep 12 '08 at 20:31
9

Sure it does. "Is there a way to hide these first chance exception messages?" - the first chance exceptions would not appear with this loop. :) – loudej Jul 09 '09 at 06:45

score 7 · Answer 5 · answered Oct 26 '12 at 11:32

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.

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

VoteCoffee · Answer 6 · 2014-04-18T18:41:33.250

5

If you want more control over these messages, you can add a handler:

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

This allows you to silence them as mentioned in other comments, but still makes sure you are able to be aware of them. I find it is good to see how many I am really throwing if I log a message and timestamp to a text file.

edited Apr 18 '14 at 18:41

answered Apr 18 '14 at 18:16

VoteCoffee

4,692
1
41
44

1

Good suggestion. But it's worth noting that System.Runtime.ExceptionServices is only available in .Net 4.0 or higher. For those of us dealing with legacy code written against .Net 3.5 (or older). – paulsm4 Jun 13 '15 at 06:33
Is valid for ***ASP.NET*** ? – Kiquenet Mar 01 '16 at 11:54
1

Thanks to this piece of code you do not need Visual Studio's built-in exception reporting in Output panel anymore and can turn it off (right-click on the Output panel and remove checkbox from "Exception Messages"). This code will report exceptions on its own (for example, using `Debug.WriteLine($"Exception thrown: '{e.Exception.GetType().FullName}' in {e.Exception.Source}");`) and it can also do some filtering, so it does not force reporting of all exceptions. – Roland Pihlakas Aug 14 '23 at 20:06

score 2 · Answer 7 · answered May 09 '10 at 21:49

2

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.

answered May 09 '10 at 21:49

AareP

2,355
3
21
28

score -1 · Answer 8 · edited Apr 26 '15 at 16:27

-1

in VB.NET:

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

edited Apr 26 '15 at 16:27

Peter Mortensen

30,738
21
105
131

answered Aug 07 '09 at 21:23

1

This has nothing to do with the question. – John Saunders Aug 07 '09 at 21:32
Actually, using [DebuggerNonUserCode] *does* hide "first chance exception" messages. I wouldn't be surprised DebuggerHidden also does this. – Ruben Dec 07 '09 at 18:23
I'm not sure if these are considered exceptions, but [DebuggerNonUserCode] won't hide any of the "Managed Debugging Assistants". For example, I get BindingFailures when I use XmlSerializer, and I've yet to find a way to hide it, other than unchecking BindingFailure when Thrown from the Exceptions dialog. – Anthony Brien Jan 21 '10 at 15:35
1

It seems that using `DebuggerHiddenAttribute` just means the first chance exception will be shown on the calling method, rather than the method itself. – Thorarin Mar 28 '13 at 12:40

score -4 · Answer 9 · answered Sep 12 '08 at 05:50

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.

Avoiding first chance exception messages when the exception is safely handled

9 Answers9

Linked

Related