Helixoft Blog

Peter Macej - lead developer of VSdocman - talks about Visual Studio tips and automation

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.

Comments   

+1 # Andy Morton 2007-01-07 01:04
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 :)
Reply | Reply with quote | Quote
+1 # Johan FranzĂ©n 2007-03-15 20:57
Big fanx! I have hated those "first chance exception" for ages, but haven't thought of the possibility to turn them off until now.
Reply | Reply with quote | Quote
0 # Quinten Miller 2007-04-11 00:16
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
Reply | Reply with quote | Quote
0 # Peter Macej 2007-04-11 09:06
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&g t; 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 :)
Reply | Reply with quote | Quote
0 # Aaron Lenoir 2007-05-04 11:58
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.
Reply | Reply with quote | Quote
0 # Peter Macej 2007-05-04 13:13
To Aaron Lenoir:
> /// If this happens this exception is thrown

Yes, that's what <exception&g t; tag in XML comment is for. But the point was, how do you know, which <exception&g t; 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.
Reply | Reply with quote | Quote
0 # Marco 2007-05-26 16:50
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!
Reply | Reply with quote | Quote
0 # Sha Mirza 2007-07-17 10:57
*************** *** Excellent! great Job Master!!!!!!!!! !!!!!!!!! my 3 cheers :) :) :)
Reply | Reply with quote | Quote
0 # mkmcgregor 2007-08-09 21:32
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.
Reply | Reply with quote | Quote
0 # Don 2008-02-05 18:17
Thank you for this tip! I've had this "A first chance exception of type 'System.Net.Soc kets.SocketExce ption' 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:Exception s to break your code in the debugger for the ones you care about, and ignroe the rest.

Thanks again!
Reply | Reply with quote | Quote
0 # Mario 2008-06-22 23:07
Holy Hannah! This is a great tip! I only wish I wasn't so lazy for so long to look for a solution that you had posted for so long! Thank you so much!
Reply | Reply with quote | Quote
0 # VikramG 2008-07-07 11:39
Hello...Great Job Man....... : )
Reply | Reply with quote | Quote
0 # VikramG 2008-07-07 11:48
Hi Friends, Am developing a driver and what i need is to share a block of memory like 16MB between my kernel driver and User applications…..
My SDMA will write into that memory block directly and my applications will just read that data and diagnose it.
Am using AllocPhysMem() API in my kernel driver but at the time while am running my application which calls my driver, an exception like “First-ch ance exception K.COREDLL.DLLâ €¦.0xC000000 5 ” is appearing.

I dont know what to do…I even googled for many hours but unable to figure it out….
Please, please, anybody please help me…..

“The exeption is appearing exactly at point when AllocPhysMem API is called”

Any reply is appreciated
Reply | Reply with quote | Quote
0 # John Welsky 2008-07-07 11:52
No way boy, i think nobody here can able to answer your question.....

Try any another forum....
Reply | Reply with quote | Quote
0 # Dave V. 2008-09-08 23:47
Thanks for the tip.

One other thing you may want to do to actually find the problem of a first time exception by going to Debug -> Exceptions... and check the Thrown checkboxes. Then debug your code and find where the exception occurs.
Reply | Reply with quote | Quote
0 # Hielke Hoeve 2008-09-15 11:30
Dis does not, however, improve performance. It will only hide the messages.
Reply | Reply with quote | Quote
0 # Steve Hiner 2008-11-05 23:58
It is my understanding that exceptions are computationally expensive to create since the stack has to be walked. While your technique will hide the messages you are, no doubt, paying a significant performance penalty for using exceptions to control the flow of your code. Exceptions are really supposed to be for "exceptional" circumstances.

I realize that, in your case, the number of loop iterations that cause an exception might make up a very small part of the over all iteration count so maybe you wouldn't see a difference in performance. I just want to make sure people realize that depending on exceptions to control program flow is highly discouraged.
Reply | Reply with quote | Quote
0 # wyck 2009-01-27 20:28
Thank you so much! You have saved my life. Come to Waterloo and I will buy you doughnuts.
Reply | Reply with quote | Quote
0 # mike 2009-06-03 15:23
I don't agree with turning off first chance exceptions. Sure many times you know what they are and can be over looked but you should investigate when this happens. If not for breaking, but even for efficiency.

An example would be inserting the same object into a list. It will throw a first chance and handle it but you might have a bug/inefficienc y that is requesting the same object to be inserted twice, or maybe you really need it to take in two copies of the object.

Turning these off will make you totally unaware of a potential conflict, and it's only in the debugger so what do you care if they pop up.
Reply | Reply with quote | Quote
0 # Joe 2009-08-13 06:29
Was driving me crazy trying to Debug.Writeline some info in a catch statement and could not see my stuff for all the "A first chance exception" messages. Thanks for the article
Reply | Reply with quote | Quote
0 # Lasse 2009-10-26 10:09
Thanks :)
Reply | Reply with quote | Quote
0 # Alberto 2010-01-30 18:09
Many thanks! It was so annoying...
Reply | Reply with quote | Quote
0 # .Netter 2010-03-15 22:14
Thanks for yet another poor soul who was suffering from a flood of these worthless messages. You rock!
Reply | Reply with quote | Quote
0 # Alex 2010-07-23 16:28
Hello and thank you for the valuable information. The "first-chance" exception dialog might become very annoying too (it pops up very often sometimes). Do you know hot to turn it out in VS2005?
Reply | Reply with quote | Quote
0 # Dan 2010-10-18 12:15
Personally, I would strongly argue against turning the messages off. Sometimes you know why they appear, and you handle them somewhere in your code. If you don't, you really should look into why they appear, because it might be that you have a serious flaw in your design.

And please don't use exceptions to handle flow logic, that is not what they are made for. It's a performance sink-hole and it's really smelly code.
Reply | Reply with quote | Quote
0 # anony 2011-12-23 02:33
i have a first chance exception on a socket beginreceive method and when its thrown, it doesnt receive on that socket anymore. so its not good to avoid these things...
Reply | Reply with quote | Quote
0 # Tony 2012-05-18 02:45
Thanks for that. You're right though, there are times when turning this off is most appricated; especially where you have to work with COM libraries that cause exceptions to be thrown. If you want to know what exceptions are happening then just Break your code when any exception is thrown. You can then filter down the range of exceptions on which to break as desired.
Reply | Reply with quote | Quote
0 # dyjams 2014-05-28 02:58
i don't think this is a wise act. What you can't see it does't mean the exceptions don't exist. There are some exceptions that waste your CPU resource so much. You must find the wrong point.
Reply | Reply with quote | Quote
0 # hongdida 2014-06-24 04:03
Quoting dyjams:
i don't think this is a wise act. What you can't see it does't mean the exceptions don't exist. http://www.keepdynamic.com/
core projects bar code generation in c#.net.There are some exceptions that waste your CPU resource so much. You must find the wrong point.


Yep, and I just learned a bloody lesson from similar act.
Reply | Reply with quote | Quote

Add comment


Security code
Refresh

 

Start generating your .NET documentation now!
DOWNLOAD
Free, fully functional trial

VSdocman

Document your .NET code on professional level.

XML comments - generate MSDN documentation and IntelliSense

Create MSDN-like class documentation with IntelliSense and F1 help for your C# and VB projects. See how easy the code commenting can be with powerful comment templates and sophisticated WYSIWYG comment editor.

More... | Download