Keep a c# windows form application running despite any unhandled exception

Question

5.00/5 (1 vote)

See more:

I am developing a windows form application for a client and they require that even if the application is stopped due to some unhandled exception or closed it should pop up again and keep running. I am a beginner with C# and would highly appreciate any help

Posted 28-Jan-13 21:25pm

09hadi

Add a Solution

2 solutions

Solution 2

The best way is to have a separate application which looks to see if the program is running - if it isn't then run it. If it checks every second or so, it shouldn't have too much overhead, and the user won't notice the gap.

If you look at this: A simple way to ensure only one instance is running.[^] and just reverse the logic you will know if it is running or not.

Posted 28-Jan-13 21:37pm

OriginalGriff

Comments

Joezer BH 29-Jan-13 4:07am

Actually you didn't answer his questions since in your Tip, the other instances are being handled within the one instance you wish to keep.
The problem he's talking about is a crash of the process.
He needs some other process to raise the application again, crash-recovery.

OriginalGriff 29-Jan-13 4:18am

That's why I said "and just reverse the logic".
Running the app if it isn't there is a trivial exercise!
Process.Start("...");
Will do it :laugh:

Joezer BH 29-Jan-13 4:21am

The thing is that the dude trying to figure out what to do with our replies, is not always skilled enough to do the math yet.

but you get my 5+ (both for the answer as well as for the Tip)

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-01-28T21:33:00

Solution 1

Good idea! I think all applications should implement it. This is extremely easy to do.

You need to do two things:

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
You need to do it before the call to Application.Run. Therefore, it's the best to do it in your entry point (Main) method. Please see:
http://msdn.microsoft.com/en-us/library/ms157905.aspx[^],
http://msdn.microsoft.com/en-us/library/system.windows.forms.unhandledexceptionmode.aspx[^].
When the above is done, you need to add a universal handle for unhandled exceptions of the UI thread. A good place to do it is in the very beginning of your main form class constructor. Handle this event:
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.onthreadexception.aspx[^].

If you do it, all exceptions thrown inside main event loop of the UI will be caught by your handler. You can handle the exception (show dialog box, for example) and continue execution.

Try it out — it will work immediately.

[EDIT]

See also my past answer where you can find more detail: How do i make a loop that will stop when a scrollbar reaches the bottom[^].

—SA

Posted 28-Jan-13 21:33pm

Sergey Alexandrovich Kryukov

Updated 29-Jan-13 9:57am

v2

Comments

Joezer BH 29-Jan-13 4:06am

That's a nice piece Sergey, however, he basically asked for a Keep-Alive methodology, the header is mis-leading.

Sergey Alexandrovich Kryukov 29-Jan-13 15:55pm

I'm not sure. Look at the body of the question, not title. As it is formulated, is is resolved exactly by the technique I described.
—SA

Adam R Harris 29-Jan-13 16:23pm

Great answer, you beat me to it.
My 5.

Sergey Alexandrovich Kryukov 29-Jan-13 16:27pm

Thank you, Adam.
—SA

Andreas Gieriet 29-Jan-13 16:34pm

I think once an unhandled exception is caught at top level (e.g. with the means you describe above), the status of the application is unknown. You can not "jump back" to the location where the exception was thrown, correct?

I've never done this, but at that point it may be best to restart the app (e.g. by either fork in the exception handler a new process and let the current process die, or by (re-)loading the executable into this app domain, see AppDomain.Load()).
Cheers
Andi

Sergey Alexandrovich Kryukov 29-Jan-13 17:00pm

You don't need to jump anywhere. This is the perfect point to catch exception: it claims some attempt to do operation failed (the user can get complete explanation of it) and continues with next operations, in other words, keeps the UI running. This approach is highly universal.

Please try it; and you will see what I mean. Actually, every application should be set up like this.

—SA

Andreas Gieriet 29-Jan-13 17:30pm

I still do not agree with "...and continues with next operation...".
That is not generally given for the UnhandledException case. Read the explanation carefully in your first reference ([...]Since UnhandledException cannot prevent an application from terminating, the example simply logs the error in the system Event Log prior to termination. [...]).
I'm aware of the UnhandledException handler and I use it in my apps, but it does not allow to "continue", it simply prevents the app of terminating with the default message.

E.g. in the case of a null reference exception thrown by some thread (resulting in terminating that thread), the state of the application may be undefined from that point on. E.g. some socket may remain open, some queue may remain in an unexpected state, some state machines may get out-of-sync, ... you name it. You may try some panic save in that handler, show some message, and. that's it.
Cheers
Andi

Sergey Alexandrovich Kryukov 29-Jan-13 17:47pm

Andi, can you make a code sample and play with it a bit? This stuff is pretty hard to discuss in words.
I use it all the time and know what I'm talking about, but the out discussion... it depends on what do you mean by "continue"? After all, you can always do exception processing in more narrow scope and "continue". Also, UI should be organized properly on application level. The thing is: due to specific nature of event-oriented UI instruction flow, this point of exception capture is the ultimate point. You catch everything which was not caught in deeper stack frames.

Null reference is no different. It means Application has a bug. And of course there is no undefined state of the state machine, but the state can be inconsistent (with preconditions, etc). You move from one state to another, and end up null reference. The stack winds up to the point where you just started the initial operation. It's responsibility of the application code to avoid unrecoverable side effect. Of course, if you application is based one a set of singleton (forget static members), you can entangled things. But literate application should run on stack. You can have well isolated and explicit FSM and operations based on stack. FSM should be very independent, tested separately and should be atomic: if you roll back some operation, it remains in a valid state.

If you do everything correctly architecturally, even if you have bugs, this in-message-loop exception remains an ultimate instrument...

—SA

Andreas Gieriet 29-Jan-13 18:04pm

I agree that in an ideal world, all fits seamlessly. In reality, I experienced different settings.
A null reference (or several other exceptions) are usually programming errors, like forgetting a using for an IDisposable, leaving some resources/handles/... open. For that reason, you might not garantee that the app is in a sane state. In some domains you prefer to reset the whole app rather than continue to run on any cost.
Everyone has to decide if "continuing" after the UnhandledException handler is safe/desired/needed for his domain of usage.
Cheers
Andi

Sergey Alexandrovich Kryukov 29-Jan-13 18:22pm

Well, this is what IDisposable is for :-) The discussion comes down to a trivial aspect: "garbage in — garbage out". Can you see it? Every perfect instrumental technique may fail to deliver if some other things are failing. In fact, none of the techniques is supposed to be responsible for everything. I already admitted that you cannot guarantee the same state, and this is obviously so. Instead, one should design state machine properly. You are just touching a neighboring aspect of the application architecture, which is of course important...
—SA

fjdiewornncalwe 29-Jan-13 16:47pm

+5. I agree with Andreas that instead of trying to jump back to where the user wass, if even possible under the specific circumstances, it would be safer to "reset" the application to a default launch state.

Sergey Alexandrovich Kryukov 29-Jan-13 17:02pm

Thank you, Marcus.
This is simpler than that. This techniques actually solves all the problem is a minimal way and almost never requires anything else. Please see my comment above.
It should always be done this way, actually. You really need to try it out, to understand it.
—SA

Tufan Chand 2-May-15 10:19am

great answer sir, thank you so much.

Sergey Alexandrovich Kryukov 2-May-15 16:04pm

You are very welcome, thank you.
—SA