Alex Rivera | Logout

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

Asked 2010-02-12T02:21:09.113
10

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.

Edit
Report

2 Answers

7

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

...?

answered 2010-02-12T04:42:55.950
3

It would make sense to cure the disease first, find out why it's causing to crash, sure the code is crashing because of obj = null or similar - using exception handling and swallowing all exceptions is just masking the problem....That's what it is not used for! It sounds like there's a lot of code-smells that is triggering the crashes - Protecting your application from crashing is not the right way to deal with it and only making things worse...

Ok, you can follow John Saunders's and pm100's suggestion to do that...but handle it in a manner to see what's the root cause, do not treat it as a 'magic silver bullet', at the end of the day, the code that is interacting with the third party application needs to be debugged thoroughly...

for instance

object foo = null;
bar baz;

// ....
// foo is now set by thirdparty app

if (foo != null && foo is bar)  baz = (bar)foo as bar;

if (baz != null){

  // Continue on, baz is a legitimate instance of type 'bar'

}else{

  // Handle it gracefully or throw a *user defined exception*

}

Notice how the 'as' is used to check if 'foo' is of the right type for 'bar' instance - now compare with this, that is a typical code smell...

object foo = null;
bar baz;

// foo is now set by thirdparty app - ARE YOU REALLY SURE ITS NON-NULL?
// IS IT REALLY OF TYPE 'BAR'?

baz = foo; // CRASH! BANG! WALLOP! KERRUNCH!
answered 2010-02-12T02:59:21.400

Your Answer