How can I swallow all exceptions and protect my application from crashing?

Question

I've found several C# application crashes in response to error conditions such as obj = null or obj.member = null. A lot of time, the obj from the interface of 3rdPartyApp. And caused both 3rdPartyApp and MyCsApp crashed together.

How could I add exception handling in all possible areas so that my application can survive in these disastrous situations? It is a challenge to add try-catch to ALL places, and recover from the situation.

How could I accomplish this in a way which is realistic, reliable and bullet-proof?

[Update: Industry Automation Control]

Structure:

GUI(asp.net, c++) - RuntimeApp (C++) - MyCsApp(cs) - 3rdPartyApp(Cs)

Normal procedure:

1. HostApp --(Connect through ethernet Cabele)-- MyCsApp
2. Operator -- GUI -- RuntimeApp -- MyCsApp

Abnormal conditions:

1. Some non-standard operation procedure;
2. some hardware issue occurred;
3. etc.

I'd better handle all the abnormall conditions. And most importantly, I must think how to recover from the situations.

Answer 1

You do not want to catch every exception everywhere.

You want to prevent exceptions from "leaking out" of the lower layers of your application up to where they can kill the application or corrupt it.

But preventing corruption is going to require more than just catching exceptions. You're going to have to make sure that the application is always safe to interrupt at every point where an exception could be thrown. This may mean that you need to clean up complicated operations. For example:

ComplexBuilder cb = new ComplexBuilder();
try
{
    cb.AddOperation(...);  // Once building starts,
    cb.AddOperation(...);  // it's not safe to use cb
    cb.AddOperation(...);
}
catch (SpecificException ex)
{
    cb.Cleanup();          // until it's cleaned up
}

// Now safe to access cb, whether or not an exception was thrown

---

I recently ran into an application with a similar attitude. There was piece of this application that was considered to be "important". When that "important" thing happened, there were other things that were supposed to happen, but which were considered "not important". The idea was that if there was an exception in the "not important" part, then it was necessary for the "important" part to continue.

What happened is that an attempt to read a resource failed for some reason. This returned null instead of the string resource. This caused an ArgumentNullException in a String.Format call. This caused the exception to be caught by code that just continued.

But between the first exception and the last one, an object was to have been allocated, and the reference to the object was to have been set. But because of the exception, setting the reference never happened. The result was that I saw a NullReferenceException, four stack levels up, and two .csproj files away from where the actual problem happened.

So when you talk about catching exceptions so that your program can continue, you need to keep in mind that the control flow of your program is changed drastically by catching all these exceptions. In fact, it could be changed so much that you can no longer determine whether it's safe for your program to continue executing.

Answer 2

This is something that a lot of developers don't get. By the time your exception catch-all gets hit, your application has already crashed. Something unexpected happened, which means that your code didn't anticipate it, and things are very likely to be in an indeterminate state (i.e. you can't be certain exactly how much of the offending function completed at the point the exception was generated, you don't know how much data got written out, what bits got set in the hardware, etc.). Is it safe to continue on? Should you try to save out the user's data? Who knows!

When you reach this high-level catch-all you're going to provide, you haven't prevented your app from crashing. You're just deciding what to do about the crash at that point. You can put up a different message than the standard:

This application has performed an illegal operation

...but what's your custom message going to say that's any better?

We're shutting down without warning for unscheduled maintenance, but rest assured that it had nothing to do with a flaw in this excellent software

...?