How To Disable “A first chance exception of type…” Messages in VS 2005
Well, all those
A first chance exception of type 'System.ArgumentException' occurred in MyAssembly.dll
messages in my Immediate window during the debugging annoyed me for a long time. Today, I said: enough! There must be a way how to tell VS not to show them.
We know that first chance exceptions don’t necessarily need to be dangerous. See What is a First Chance Exception? and First and second chance exception handling. I’m using exceptions very often and I handle all of them very carefully. There never appears second chance exception in my code. I’m getting exceptions when trying to add duplicate item to hashtable or trying to get the item with the key which doesn’t exist in custom collection. Doing it in countless loops, I’m getting hundreds of warnings at debug time. Some may say that this is poor design. Yes, I could use millions of If ... Then checks to avoid exceptions but I think that avoiding this is one of the exceptions purposes.
So how do we suppress the messages? You most likely see these messages in Immediate Window because you have set Redirect all Output Window text to the Immediate Window in Tools - Options… - Debugging - General. That’s why when you right-click in Immediate Window, you cannot see any option to disable messages. It’s Output Window text and thus you need to set it in the Output Window. So open Output Window, right-click and uncheck Exception Messages from context menu. Simple but it took me one hour to find it.
January 7th, 2007 at 2:04 am
Thank you thank you thank you! That’s been driving me nuts for absolutely ages. Amazing - such a simple solution to ease my headaches. You are a certified genius
March 15th, 2007 at 9:57 pm
Big fanx! I have hated those “first chance exception” for ages, but haven’t thought of the possibility to turn them off until now.
April 11th, 2007 at 12:16 am
Thanks for this useful bit of information. I have a question regarding exceptions in C#. I’ve only recently come over to .NET from many years of Java programming. Exceptions in Java are slightly different, if you try and call code that will throw an exception you MUST handle it (in one of two ways). This does not seem the case in C#. Is there an way to discover if a method throws and exception? In Java the method declaration included the exception type(s) thrown.
Cheers
Q
April 11th, 2007 at 9:06 am
You are right. AFAIK, there is no way to determine whether the method throws an exception in .NET. Unlike Java, the .NET compiler doesn’t force you to catch exception or explicitly declare it in the method signature. It would be great if it worked Java way because our VSdocman could automatically generate <exception> tags for the method comments. Moreover, I’m not aware of any add-in that can find method exceptions. Maybe I should play with it
May 4th, 2007 at 11:58 am
Actually you can just add some XML document above your methods… this will give others some indication of what your code throws:
///
/// This method does something
///
/// If this happens this exception is thrown
Gives you some information when you watch the method info trough the object browser and stuff… offcourse, this is just extra information you don’t HAVE to give.
May 4th, 2007 at 1:13 pm
To Aaron Lenoir:
> /// If this happens this exception is thrown
Yes, that’s what <exception> tag in XML comment is for. But the point was, how do you know, which <exception> tags you should add to your method? What if your method calls 20 other methods, where each of them throws say 3 exceptions? If you don’t catch those exceptions, they will bubble to your method’s caller. So you need to find MSDN documentation for each method you are using to see which exceptions they throw. Then you need to add all those exceptions in your XML comment. This is not very convenient.
As mentioned, Java compiler doesn’t allow this. It will force you to either catch every possible exception or explicitly define which exceptions your method will bubble.
May 26th, 2007 at 4:50 pm
If you only knew how often I googled this to find the answer. I dupplicated your answer with a variation on your title on my blog. Maybe other people find it as well.
Thanks!
July 17th, 2007 at 10:57 am
****************** Excellent! great Job Master!!!!!!!!!!!!!!!!!! my 3 cheers
August 9th, 2007 at 9:32 pm
This is a good thought, however that also eliminates ALL other exceptions that really do matter. To many people hided errors by putting a generic catch that does nothing. Also, this would hide useful exceptions like trying to update a control while in a thread; an all too common problem in managed code. Atleast VS2005 warns you with the exception, but not if you prevent exceptions from being displayed.
February 5th, 2008 at 7:17 pm
Thank you for this tip! I’ve had this “A first chance exception of type ‘System.Net.Sockets.SocketException’ occurred in System.dll” trash obscuring my output window for far too long (making it almost impossible to find the output I really care about).
Too bad VS doesn’t provide a more useful filter. As mkmcgregor points out you have to do an ALL or NOTHING filter on exceptions in the output window, but you can still set the Debug:Exceptions to break your code in the debugger for the ones you care about, and ignroe the rest.
Thanks again!