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.

gnat
  • 21,442
  • 29
  • 112
  • 288
Björn Lindqvist
  • 264
  • 2
  • 10
  • random blog posts seem nice... – ratchet freak Dec 04 '13 at 21:05
  • 2
    This link might help - http://stackoverflow.com/questions/7570719/learning-exception-handling-patterns – DFord Dec 04 '13 at 21:08
  • Code Complete? [MSDN](http://msdn.microsoft.com/en-us/library/seyhszts.aspx)? –  Dec 04 '13 at 21:20
  • Great answers below. Plus, "WTF?!?". Anyone who thinks that logging and ignoring exceptions is a good idea just needs a "WTF?!?" :-) – Ross Patterson Dec 04 '13 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 04 '13 at 23:23

3 Answers3

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.

munificent
  • 2,029
  • 13
  • 11
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 :)

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
Alex Dresko
  • 191
  • 4
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.

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
Kyralessa
  • 3,703
  • 2
  • 19
  • 20