Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Hijacking UnhandledException to keep Multi-Threaded Application Running

Tags:

c#

.net

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.

like image 743
Mehdi LAMRANI Avatar asked Jan 19 '12 10:01

Mehdi LAMRANI


People also ask

How to pass unhandledexception from one thread to another?

You need to attach an event handler to UnhandledException event on the Current AppDomain: AppDomain.CurrentDomain.UnhandledException += UnhandledExceptionHandler Inside the handler, you will have to somehow save enough state (to a file, database, etc.) for the restarted application to pass along to the new threads.

What is an unhandled exception in the framework?

In the .NET Framework versions 1.0 and 1.1, an unhandled exception that occurs in a thread other than the main application thread is caught by the runtime and therefore does not cause the application to terminate. Thus, it is possible for the UnhandledException event to be raised without the application terminating.

What is an unhandledexception in Windows Runtime?

For example, if the Windows Runtime invokes app code like an event handler, and the app code throws an exception and does not catch it, the exception will propagate back to the Windows Runtime. The Windows Runtime will then fire the UnhandledException event to notify the app of this exception.

How do you handle unhandled exceptions in Windows Forms?

To catch exceptions that occur in threads not created and owned by Windows Forms, use the UnhandledException event handler. To guarantee that no activations of this event are missed, you must attach a handler before you call Application.Run. Only one handler can be attached to this event.


3 Answers

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.

like image 164
Henk Holterman Avatar answered Nov 01 '22 16:11

Henk Holterman


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.

like image 23
Jaster Avatar answered Nov 01 '22 17:11

Jaster


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.

like image 31
HTTP 410 Avatar answered Nov 01 '22 17:11

HTTP 410