Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

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.

share|improve this question

closed as off-topic by GlenH7, Robert Harvey, svick, gnat, Bart van Ingen Schenau Dec 5 '13 at 9:50

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – GlenH7, Robert Harvey, svick, gnat, Bart van Ingen Schenau
If this question can be reworded to fit the rules in the help center, please edit the question.

random blog posts seem nice... – ratchet freak Dec 4 '13 at 21:05
This link might help -… – DFord Dec 4 '13 at 21:08
Code Complete? MSDN? – user40980 Dec 4 '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 4 '13 at 22:57
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. – Ӎσᶎ Dec 4 '13 at 23:23
up vote 12 down vote accepted

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.

share|improve this answer
Thanks. Can you please link to the page that contains your exact quote? I cannot find it among the pages you linked to. – Björn Lindqvist Dec 4 '13 at 22:10
@BjörnLindqvist See – Ross Patterson Dec 4 '13 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 '13 at 6:11
Thanks! Probably can't find a link more authorative and explicit than that. Though I'd love to see someone try. :) – Björn Lindqvist Dec 5 '13 at 8:23

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 :)

share|improve this answer

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.

share|improve this answer

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