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

That all depends on how you treat exceptions. If you only throw exceptions when something truly exceptional has happened (and not when a database query return no results, or is ill-formed) then you really shouldn't need to ever catch exceptions. Because your program shouldn't be able to recover, anything you can recover from is not an exception, but an error.

Answer 2

You can always setup a custom error handler and ignore catching exceptions that you aren't prepared to handle. Trying to recover from unknowns may have negative consequences too if the right conditions are met. But then again, that really does depend on what the exception is and how you're handling them.

On the other hand - I think people get to overwhelmed with the whole "exceptions are evil" mentality. They are a tool, and if used appropriately, can have astonishing perks. However, many people misuse them by wrapping root with catch(Exception)..

Answer 3

Since you don't know what every subclass of Exception IS, you simply CANNOT know it's OK to catch them. Therefore, you should mind your own business: catch exceptions you know and care about, which will mainly be the ones you've explicitly created for your own program, or the ones created for errors from the library calls you're using. In particular, catching the Exception class is just lazy, bad programming --- essentially, you're saying "I don't care what the problem is, and don't tell me; just do this." Take a look at how java programs handle exceptions, as the exception handling practices there are usually pretty good.

Answer 4

If you can't handle the problem adequately--and if it's anything other than rejecting bad input in some form (this includes something you tried to read from the disk or web) you probably can't--then you should die. Unless you're 100% certain you can continue safely, don't.

However, I wouldn't simply let an exception go. Catch it and gather as much information as you can. If your program manipulates a document of some kind save it UNDER A NEW NAME--it might be corrupt, you don't want to overwrite the original.

Answer 5

I think it depends on what kind of app you are running and what the consequences of 'dying' are. For many client apps, dying is awesome. For servers, often not so much (and swallow-and-log is appropriate). There's no one-size-fits-all solution.

Answer 6

Also known as Offensive Programming.

You should check out, "Offensive Programming: Crash Early, Crash Often".

Which is a very different ideology from the norm of Defensive Programming:

[Defensive Programming] is intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software.

I personally like the "Crash Early, Crash Often" philosophy.

I've seen far too many:

try  
{  
    // ... Huge block of code goes here  
}  
catch(Exception ex)  
{  
   // Do nothing...  
}  

Which is far worse than crashing hard. If exceptions are handled properly then a little defensive programming is fine.