5

My work place suffers from a bad case of the Pokemon Exception Handling anti-pattern with constructs like the following splattered across the code base:

try {
    ...
} catch (Exception ex) {
    // Log and pretend nothing happened.
    Log.LogException(ex);        
}

I've found lots of answers on Stack Exchange sites that explains why the above is bad. But I haven't found any authoritative sources, like books, developer journal articles or msdn pages explaining why you shouldn't write code like the above. Are there any sources like that, if so, where?

Edit: I'd say that "famous" bloggers also count as authoritative sources. My rule for what counts as authoritative or not is not exactly set in stone.

5
  • random blog posts seem nice... Dec 4, 2013 at 21:05
  • 2
    This link might help - stackoverflow.com/questions/7570719/…
    – DFord
    Dec 4, 2013 at 21:08
  • Code Complete? MSDN?
    – user40980
    Dec 4, 2013 at 21:20
  • Great answers below. Plus, "WTF?!?". Anyone who thinks that logging and ignoring exceptions is a good idea just needs a "WTF?!?" :-) Dec 4, 2013 at 22:57
  • 1
    Don't knock it. I once wrote a powershell script that ran over ~1/2 million lines of code and #ifdef'd away ~40k occurrances of this antipattern. Plus a weekend of fixing the mismatch cases. It had to be conditional so we could work on fixing them in the background while continuing to ship "working" releases.
    – Móż
    Dec 4, 2013 at 23:23

3 Answers 3

12

In C#, you couldn't ask for a more authoritative source than the Framework Design Guidelines. This is what the authors of the .NET Base Class Library followed when designing the core libraries that come with .NET. It includes comprehensive guidelines on how to work with exceptions.

In particular, it says:

AVOID swallowing errors by catching non-specific exceptions such as System.Exception, System.SystemException, and so on, in application code.

4
  • Thanks. Can you please link to the page that contains your exact quote? I cannot find it among the pages you linked to. Dec 4, 2013 at 22:10
  • 1
    @BjörnLindqvist See msdn.microsoft.com/en-us/library/ms229005(v=vs.100).aspx Dec 4, 2013 at 22:55
  • Thanks, @RossPatterson, I added your link to the answer. I couldn't find it online and actually got the quote from my print copy of the book.
    – munificent
    Dec 5, 2013 at 6:11
  • Thanks! Probably can't find a link more authorative and explicit than that. Though I'd love to see someone try. :) Dec 5, 2013 at 8:23
5

John Skeet and Eric Lippert. I dare you to find someone in the .NET world with more brain power. :)

I'd start here: Vexing Exceptions by Eric Lippert

Then look for anything by either of them related to exceptions. Also +1 to the Clean Code book comment. Clean Code by Robert Martin :)

1

Here's an article from Krzysztof Cwalina, a Principal Architect at Microsoft. It was written six years ago, but it's still my go-to for reminding myself what to do about various exception types:

How to Design Exception Hierarchies

He divides up exceptions into three types:

  • Usage errors, such as a NullReferenceException, fixed by correcting your code.
  • Logical errors, such as FileNotFoundException, that technically can't be avoided. (Even if you use File.Exists, someone could delete it between when you check and when you use the file.) You have to handle these.
  • System failures, such as OutOfMemoryException, which you can't handle.

There's a lot of good information in the article.

Not the answer you're looking for? Browse other questions tagged or ask your own question.