Do something on an uncaught exception.

  • Thread starter Thread starter Bob
  • Start date Start date
B

Bob

Hi all,

I have a small helper service that is peppered with try-catches for all the
exceptional cases I could think of.
It industriously logs every error it comes across for debugging later on.

Wonderful; however on the odd time it blows a gasket the solution is in
99.9% the same .. restart the service.
Then go away and track down the source of the bug fix-test-deploy.
usually a 5 min fix .. but often a call at 3am ...

Is there a mechanism for catching these "uncaught" exceptions in the
application so that I could then launch another instance of the service and
gracefully close down the 'afflicted' app.

regards Bob

p.s. .. I'm sure explorer.exe does this .. it seems to hang and restart all
the time.
 
Bob said:
Hi all,

I have a small helper service that is peppered with try-catches for all
the exceptional cases I could think of.
It industriously logs every error it comes across for debugging later on.

Wonderful; however on the odd time it blows a gasket the solution is in
99.9% the same .. restart the service.
Then go away and track down the source of the bug fix-test-deploy.
usually a 5 min fix .. but often a call at 3am ...

Is there a mechanism for catching these "uncaught" exceptions in the
application so that I could then launch another instance of the service
and gracefully close down the 'afflicted' app.
Click to expand...

Application.ThreadException += new blah....

I'm not sure if you need to do this for each thread you create so it would
be worth testing here. With a service though don't you have a single point
that calls all code so can trap everything there? This is what I have and
don't need to restart the service.

Michael
 
Application.ThreadException += new blah....
Click to expand...

If that does not catch everything you might also try the

AppDomain.CurrentDomain.UnhandledException += ....


hth,
Alan.
 
I am assuming that you are in .net. If so then above the page level which you seem to be catching there are the application level of global.aspx and also the last level below the server of web.config. Both have error traps that you can use. However, there are some errors that are a the server level that never get to the application and those are handled by the server. Look at Application_Error in global.aspx; and customerrors in the web.config.

EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com
 
Michael said:
Application.ThreadException += new blah....

I'm not sure if you need to do this for each thread you create so it would
be worth testing here. With a service though don't you have a single point
that calls all code so can trap everything there? This is what I have and
don't need to restart the service.
Click to expand...

Application.ThreadException is documented as handling any exception that
may occur in the application's UI thread, so there's only one thread
this event applies to. Correct?

I'm wondering if a service application even has a UI thread like a
Windows Forms application does. If not, is there any point in calling
Application.ThreadException in a service application?
 
GlennDoten said:
Application.ThreadException is documented as handling any exception that
may occur in the application's UI thread, so there's only one thread this
event applies to. Correct?

I'm wondering if a service application even has a UI thread like a Windows
Forms application does. If not, is there any point in calling
Application.ThreadException in a service application?
Click to expand...

In a service most code will start from a single point which will probably be
a timer, so it's easy to catch any exception there.
 
In a service most code will start from a single point which will probably be 
a timer, so it's easy to catch any exception there.
Click to expand...

Except for thread pool threads and asynchronous callback threads. For instance,
an exception thrown in a handler for completion of a socket receive needs to be
handled in a try/catch handler (or by the handler for
AppDomain.CurrentDomain.UnhandledException) as Allan suggested.

Mike
 
Mike Blake-Knox said:
Except for thread pool threads and asynchronous callback threads. For
instance,
an exception thrown in a handler for completion of a socket receive needs
to be
handled in a try/catch handler (or by the handler for
AppDomain.CurrentDomain.UnhandledException) as Allan suggested.
Click to expand...

Excellent suggestion. This could be a problem in my service, I noticed some
exceptions not getting handled when I was developing even though I thought
everything should be caught. I think I probably eliminated them just by
fixing whatever was causing the exception but it would definately be worth
me revisiting it. Thanks for the tip.

Michael
 
Back
Top