CODEWITHSUNDEEP
c#.net
Mehdi LAMRANI
Mehdi LAMRANI

Reputation: 11597

Hijacking UnhandledException to keep Multi-Threaded Application Running

Situation
Well, as you can see below, I have a main App, creating a thread, which creates a bunch of background workers. When the RunWorkerCompleted is fired on some BG worker, I sometimes end up dropping an Unhandled Exception, (for a reason I have clearly pinpointed, but this is not the matter).

architecture

So the Logs clearly show that my UnhandledException handler is entered and reports the exception. I know I am deliberately misusing the OnUnhandledException by stopping the App from exiting, using a Console.Read(). I did it on purpose because I want a human intervention/check before terminating the app.

    public static void OnUnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
      Logger.log("UNHANDLED EXCEPTION : " + e.ExceptionObject.ToString());
      Mail.Sendmail("ADMIN ALERT : " + e.ExceptionObject.ToString());
      Console.Read(); // Yes, this is an ungraceful trick, I confess.
    }

However, what was supposed just to be a "pause" before manual exit turned out to keep the App alive, ie, the Thread is still generating workers, and running as if nothing happened. Even Weirder : The UnhandledException is still being dropped from time to time when it happens again. And it is logged each time, behaving just as if it was a plain ol' try catch. (This was the default behaviour before .Net 3.0)

Question
So, why is everything happening as if the UnhandledException was not thrown, and the thread and BG's keeping running as if nothing happened ? My guess is that as long as the OnUnhandledException handler is not done, and the App is still alive, all running threads that are still alive keep on living in a free world and doing their job.

This gives me a bad temptation, which is to keep this design, as a try/catch to unHandled Exception.
I know this is not a tidy idea, as you never know if the exception is serious or something that could be skipped. However, I would really prefer my program to keep running all day and watch the log report / mail alerts and decide for myself if it needs to be restarted or not. As this is a server application that needs to be running 24/7 I wanted to avoid ill-timed and repetitive interruptions due to minor still unhandled exceptions. The biggest advantage to that being that the server program keeps running while we are tracking down unhandled exceptions one by one and deliver patches to handle them as they occur.

Thank you for your patience, and please feel free to give feedback.

PS : No, I did not smoke pot.

Upvotes: 8

Views: 888

Answers (3)

HTTP 410
HTTP 410

Reputation: 17608

If you want to allow a BackgroundWorker thread to fail without killing the whole process, there's a cleaner way to do this.

First, intercept the RunWorkerCompleted event. This event is raised when the BackgroundWorker thread terminates, either normally or via an unhandled exception. Then in your event handler, check for the unhandled exception:

// Runs when the BackgroundWorker thread terminates.
private void ThreadFinished(object sender, RunWorkerCompletedEventArgs e)
{
    // Process any unhandled exception
    if (e.Error != null)
    {
        this.LogError(e.Error.Message, e.Error.StackTrace, blah, blah);

In this way, you can let the BackgroundWorker thread die and log any exception without terminating the whole process.

Upvotes: 1

Henk Holterman
Henk Holterman

Reputation: 273274

My guess is that as long as the OnUnhandledException handler is not done, and the App is still alive, all running threads that are still alive keep on living in a free world and doing their job.

Correct. But your other threads are now doing their job in a potentially unstable process. There are good reasons for terminating the App when an unhandled exception happens.

I would really prefer my program to keep running

Besides the (potential) stability problems, you would accumulate the halted state of whatever is involved in the unhandled handling. My guess is that you would at least leak a Thread each time it happens. And you can't spare too many of them.

So it would be a very bad design, and only delay the crashing.

Upvotes: 3

Jaster
Jaster

Reputation: 8579

First of all you need to subscribe the UnhadledThreadException handler. There you can not "Hijack" the exception, but you have access to it and also to the thread it belongs. What you can do now is putting the throwing Thread into suspetion. The Thread will be still alive!! This however is a bad, dirty hack! Do not do this!

Take a look at this article for some details.

I recommend switching your threading model to TPL (design remains). There you have access to those ugly cross-thread excepions and can handle/supress em gracefully.

Upvotes: 2

Related Questions