Console application thread exception handling

[Nak]

Hi there,

I have a very simple console application that I'm trying to handle the
thread exception on, as I understand it there is no Application object
available to a console application, so I can't use this. Instead you need
to use "Thread.GetAppDomain.UnhandledException", this "works" to a certain
extent but from the look if it you merely get added to a chain of event
handlers, and the runtime is still above you, so I can't use this because
the "unhandled exception" dialog appears *before* my event is even fired.

Does anyone have any other ways of achieving this? I need to be able to
catch *all* unhandled exceptions in a console application within the same
event preferably. Cheers in advance.

Nick.

 

[Nak]

Not to worry, I've resolved the issue by creating a new threading and
joining it. Now any exception that occurs in this thread is handled by me
first and not the system.

Nick.

 

[Jay B. Harlow [MVP - Outlook]]

Nick,
You are correct, using Addhandler on AppDomain.UnhandledException adds
yourself to the end of chain of handlers, normally you will be the only
handler.

Remember http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx
states that "unhandled exceptions that occur on the application's main
thread cause the application to terminate".

Ergo the Main routine is special, it effectively has an extra "handler",
actually I suspect Main itself is in a Try/Catch block, & its this Try/Catch
that you are seeing.

Normally I use AppDomain.UnhandledException in my Console applications, plus
I have a Try/Catch wrapping any logic within Main, especially if its of any
consequence.

Depending on what this Console application is doing, creating a new thread
or putting a Try/Catch in Main either or both may be needed.

Unfortunately I don't know of an easy way to call the list of handlers on
AppDomain.UnhandledException like Application.OnThreadException provides for
Application.ThreadException's list of handlers... I normally just have the
Try/Catch in Main & AppDomain.UnhandledException to both call the same
common routine. Alternatively the Try/Catch in Main can simply call your
handler on AppDomain.UnhandledException, especially if you know you will
only have one.

Hope this helps
Jay

 

[Nak]

Hi Jay,

You are correct, using Addhandler on AppDomain.UnhandledException adds
yourself to the end of chain of handlers, normally you will be the only
handler.

Remember http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx
states that "unhandled exceptions that occur on the application's main
thread cause the application to terminate".

Aah, that would make sence why creating a new thread solved my issue.

Ergo the Main routine is special, it effectively has an extra "handler",
actually I suspect Main itself is in a Try/Catch block, & its this
Try/Catch that you are seeing.

Normally I use AppDomain.UnhandledException in my Console applications,
plus I have a Try/Catch wrapping any logic within Main, especially if its
of any consequence.

I've taken the same approach as yourself on a few occasions, only
handling the application entry point for "unhandled exceptions". It's
worked well but I thought I'd try a different angle.

Depending on what this Console application is doing, creating a new thread
or putting a Try/Catch in Main either or both may be needed.

Yup, just what I ended doing.

Unfortunately I don't know of an easy way to call the list of handlers on
AppDomain.UnhandledException like Application.OnThreadException provides
for Application.ThreadException's list of handlers... I normally just have
the Try/Catch in Main & AppDomain.UnhandledException to both call the same
common routine. Alternatively the Try/Catch in Main can simply call your
handler on AppDomain.UnhandledException, especially if you know you will
only have one.

It would be nice to be able to clear event handlers but then again I
should imagine the framework would become a whole lot insecure wouldnt it?

Cheers for the help, much appreciated, sorry I haven't got time to type
more! Cheers...

Nick.

 

[Jay B. Harlow [MVP - Outlook]]

Nick,

It would be nice to be able to clear event handlers but then again I
should imagine the framework would become a whole lot insecure wouldnt it?

As you know, you can use RemoveHandler to remove one of your handlers from
any event.

If its your event, you can change the underlying list of event handlers. If
your class has "MyEvent" there will be a hidden "MyEventEvent" field that is
the underlying delegate. Setting this field to Nothing effectively clear the
event handlers...

VS.NET 2005 (aka Whidbey, due out later in 2005) will allow "custom events",
where you can have control over what delegate the events are stored in:

http://msdn2.microsoft.com/library/6hwhs172.aspx
http://msdn2.microsoft.com/library/yt1k2w4e.aspx
http://msdn2.microsoft.com/library/wf33s4w7.aspx

With "custom events" clearing the list should be easier, at least not rely
on an undocumented feature ;-)

Now whether you should clear the list of handlers or not is a matter of
another discussion

Hope this helps
Jay