Is “Dying is Awesome” preferred?

Question

Recently I attended Jeffrey Richter\'s training courses about .NET. He mentions one strategy of coding \"Dying is awesome\". That is, don\'t write \"catch (Exception ex)\" e

Answer 1

Karl Seguin says the following about exception handling:

1. Only handle exceptions that you can actually do something about
2. You can't do anything about the vast majority of exceptions

Good intro to the subject.

Answer 2

I am not familiar with Richter's material, but I think the philosophy/justification is that in the vast majority of cases there is really nothing that the program can do to recover from an unhandled and unexpected exception.

Letting the program die in front of a user, however, is not a very good idea - it leaves a very bad impression. I prefer to log unhandled exceptions to a database, notify the developers, and track them to make sure that they get fixed.

Then again, I sell a product for exactly that purpose, so I am a bit biased in this area!

Answer 3

Sounds like Guruspeak

This sounds like another one of those general guidelines preached by gurus that is not a bad piece of advice in itself. However, this guideline could easily be applied to places where it does not belong. I think the key phrase to remember that you used above was "one strategy of coding" because this stategy is very useful in certain domains, yet can be quite harmful in others.

Dying is awesome - if you have a lot of tightly coupled components whose state depends on each other, then an exception could easily be a catastrophic event. However, one of your goals should be to code in such a way that a single failure does not have to bring down the entire system (notice goal).

What would you think of the following applications dying on a run-of-the-mill exception:

• Medical Devices
• Power Plants
• Intrusion Detection Systems

For exceptions that you are catching in try / catch - you really should be expecting them and handling them. For all other cases, it is good to fail fast to a predicted run-level. So, if you are at a network or web handler, why not just have the current operation die? Do you really need the whole app to go down?

This becomes increasingly important if you are developing an app that is mission critical and has a public interface. If there are exceptions available that can bring the app down, then that becomes a vector of attack for black-hat hackers intent on causing a denial of service attack.

The edge cases of abusing this strategy are a little too big to give it much praise. A much better approach, is to solve the problem of your domain. Understand what this stategy is getting at and apply the appropriate parts to your problem.

Caveats: I work on server-side systems where uptime and security is critical.

EDIT: I guess I got confused by what was meant by "process die" - was this a reference to the entire app or just the running thread, etc?

Answer 4

What does your customer expects?

It all comes back to that. If the customer can handle the program dying and they can restart it, so be it.

Sometimes, it is better to let a process die and create another to handle requests.

Sometimes, it is better to attempt to resolve the problem.

Answer 5

Nothing destroys user confidence faster than a stack trace. At a minimum, catch the exception and log as much information as you can. Then provide the user with a friendly message and instructions as to what to do to either work around the issue or report the problem to support.

There is concern here as to continuing in an indeterminate state. If this is a web app, then this is not a problem unless you are overly dependent on session and app state. If this is a windows app, then feel free to exit (after giving the user a chance to save).

Answer 6

There's one advantage of not handling any exceptions at all. If there's a problem, you'd rather have a crash and the user complain, instead of having the program continue in an indeterminate state.

For example, if you're writing a real time trading system, and there's an unexpected error, you're better off letting it crash. Otherwise, your program might keep going and make stupid trades. The users will complain right away "WTF?", but at least you don't lose millions of dollars.