If it takes forever to start your app with the debugger, check for thrown exceptions – level 300

Overview of Exceptions
There are quite of a few things that are just laws of Object-Oriented development, and one of those is that exceptions should be avoided. If you can prevent an exception from being thrown, do it. In the world of managed runtimes, particularly Java’s JRE and .Net’s CLR, objects are “thrown” to communicate errors. In a try/catch block, the language limits objects that can be thrown to ones that derives from System.Exception, or java.lang.Throwable in Java. When an object is “thrown”, the runtime stops and assembles the callstack and some other information and gives code at all levels of the callstack an opportunity to catch the thrown object (exception) and do something with it. If the exception is never caught, the runtime with catch it and terminate the program.

Clearly, exceptions being thrown in code is a bad thing, and it signals and unstable state in the program. It may be a huge bug, or the network may have gone down. Either way, and exception is thrown. Proper error handling with catch the exception at a point high enough in the callstack where the program can actually make a decision to do something about it.

Swallowing exceptions (wrapping code in a try/catch where the catch block is empty) leads to less feedback. An exception will happen, but it will be swallowed, and you won’t know about it. As soon as you start swallowing exceptions, they will start happening without being noticed. Debuggers pay special attention to exceptions, so swallowed exceptions (thrown, immediately caught, and ignored) will slow down the debugger with each occurrance.

Solution
Go to the Debug menu in Visual Studio and select Exceptions. CTRL+ALT+E is the shortcut. Check the checkbox for “Common Language Runtime Exceptions”. Now when you start your debugger, it will break when a managed exception is thrown. It will break on the line from which the exception originates. You can use this technique to find all the exceptions that are happing in your software right under your nose. If you refactor to keep those exceptions from happening, you’ll see a marked improvement on debugger load time (provided there were a large number of exceptions happening previously).

Alternatives
The alternative to debugging often is automated tests. When each small piece of code is verified independently, you don’t have much occassion for running the full application in debug mode. If you have unit tests as part of your automated test suite, a failure will point to the exact place where you have the problem.

Rule to live by
Fail fast. Fail fast. If your software is going to fail, make it fail quickly so that you can get the feedback earlier and fix it earlier. Don’t hide the problem by ignoring it or burying it in a log file that’s already verbose. If you are unfamiliar with this concept, read this article by James Shore.

Don’t use an exception as a return value. In an ideal situation, your application should run with 0 exceptions. You may have a library that swallows an exception, and that would be unfortunate, but keep your application code clean. If you can anticipate an exception happening, perform some checks to avoid it being thrown.

How to keep an eye on exceptions
Use Perfmon. Watch the counter “.Net CLR Exceptions# of Exceps Thrown”. The number should be zero in an ideal situation. If you have an app that can’t avoid some exceptions, you can watch “# of Exceps Thrown / sec”. This number should be close to zero. If your application is constantly throwing exceptions under ideal circumstances, you have some work to do.

[tags: exceptions, programming, c#, java, failfast, objectoriented, development, .net, clr]

David Yates 2:57 pm on August 17, 2006

Jeff,

My only comments is that even if you don’t turn on all the
“Common Language Runtime Exceptions” a first chance exception is still printed to the output. I have dual monitors, so I have pulled mine out of the page control and placed it on my second monitor while I’m running in the IDE. If I spot an error, I do as you suggested.

Question:
In an ASP.NET application, how would you handle an unhandled exception that bubbles all the way up to the user interface?

How would you handle it in a winforms application?

I know how I handle it, but I’m interested in your take on the subject.

Dave
jpalermo 3:10 pm on August 17, 2006

David,
You are absolutely right. That can tip you off to find out where these exceptions are coming from.

I typically set up my user interfaces to have a global catch all that can communicate to the user that something went wrong and to notify support. In ASP.NET, I have an Error.ascx user control that I invoke and display if an exception bubbles up. In Winforms, I’ll show a message box.
Tomas Restrepo 4:18 pm on August 17, 2006

I tend to follow Jeffrey’s suggestion: Always have an unhandled exception handler in your WinForms app, and make sure you hook up to all relevant events:
http://www.winterdom.com/weblog/2006/08/05/ExceptionHandlingVSTOOutlookAndOtherTopics.aspx
Ayende Rahien 9:40 pm on August 17, 2006

Jeffrey,
How do you handle this in a critical application?
Case in point: I have an application where the defination is that nothing short of a reboot should stop the app. And that means that I need to handle exceptions fairly close to where they start (I have a shallow call stack in this app).
jpalermo 9:53 pm on August 17, 2006

Ayende,
I would handle it the same way. If a class can’t make a correct course of action when an error happens, it should report up. Eventually, you will get high enough where a class does know what to do.

In a Windows service I’ve worked on, I had a similar situation. It would continually work, and it should never stop. I had a wrapper around the code that started and repeated the work, and if something bubbled up, I’d log it, reinitialize the work, and start it over. A few times, something major got to that (wrong DB connection string), but the service never stopped. I had to fix the DB connection string, though.

At the very least, you should have a top-level catch-all for the unexpected. My advice is to handle exceptions where you can handle them, but no lower. Ignoring an exception != handling.
Tomas Restrepo 11:45 pm on August 17, 2006

Ayende,

Besides Jeffrey’s answer, I think one key point here is that it doesn’t necessarily mean that you need to trap the exceptions very close to where they start (though you seem to suggest this might be your case because of your design), but instead it is about identifying key points in the code that should be exception boundaries.

For example, even though you might have a global unhandled exception handler, if you’re spawning threads chances are you might want to make the threaded method an exception handling boundary. Or perhaps you’re using the threadpool, then you’ll want the method fired by the threadpool to be an exception handling boundary as well. If you have command-driven, Unit-Of-Work and facade driven code scenarios, then those are likely candidates as well.

I’ve had good results applying this.
Ayende Rahien 12:38 pm on August 18, 2006

The general path is something like:

Start service:
– Perform Validation on config (include connection string)
– If fail, log and stop
– Start service (basically a work manager)
– An event occurs (time related or file arrival related)
– Queue on thread pool
– try:
– Start task
– catch:
– Log error

– Tasks
– Execute something
– (Usuaully start transaction)
– Do Work

But some tasks may need to process stuff that are failure prone by their nature (calling Web Service), and raising an exception may rollback existing transactions.
This means that in certain cases I have something like:

– transaction:
– Get Data
– try:
– Send to WS
– Update status to success
– catch:
– log error
– Update status to failed
– save
– commit

I allow myself to ignore the higher level exception handling in those cases because I know what the conditions to failure are, and I know that there is nothing they can do that I can’t do locally.
Tomas Restrepo 4:06 pm on August 18, 2006

Ayende,

That sounds good, and seems pretty inline with what I mentioned before: your tasks might be (or are) exception boundaries, and that’s seems just fine.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

If it takes forever to start your app with the debugger, check for thrown exceptions – level 300

Related