Why do good programmers sometimes silently swallow

Question

I know it's evil, but I've seen swallowed exceptions in code written by a good programmer. So I'm wondering if this bad practice could have at least one positive point.

In other words, it is bad but why do good programmers, on rare occasions, use it?

try
{
    //Some code
}
catch(Exception){}

Answer 1

I believe it's because of Java's checked exceptions. I personally hate them because of this because people tend to think they need exception-handling code everywhere. IMO in 99% of the code you should just be throwing your exception up the stack and not handling it. I'd be happy if the default signature for any new method created had 'throws Exception' in it so that I don't have to deal with exceptions unless I want to.

IMO you only need exception-handling in two places: 1. For resource cleanup like closing an input stream, database connection or deleting a file. 2. At the very top of the stack where you catch the exception and either log it or show it to the user.

There are places where you really don't need to do anything in the catch such as handling the InterruptedException from Thread.sleep() and there you should at least have a comment to make it clear that you really don't want anything to happen there.

Answer 2

I've done this when there some is some piece of code where regardless of it failing I want the program to continue. For example I've opened an optional log file and regardless of why it failed to work I want to continue the execution of the program.

Even so though, it's not good code as you can get exceptions like out of memory exceptions that ignoring makes no sense at all so even though i've done it, it's still not the best idea and I wouldn't admit to doing it in public. (oops...)

I've done it on programs that are intended to be run once to convert some data or something just to shut the compiler up. That's an entirely different situation to any form of production code though.

Basically there is no good reason for doing this other than lazyness.

Answer 3

I'd argue that a good programmer wouldn't do that without explaining it.

try
{
    //Some code
}
catch(Exception e) {
    // Explanation of why the exception is being swallowed.
}

I'm very unlikely to just silently swallow the base Exception class though, for any reason. I'd at least try to log the error.

---

Here's a concrete example that I just happened to run across today in my project. This is part of a JavaScript function that gets an XMLHttpRequest supported by the browser.

var XMLHttp = null;

if( window.XMLHttpRequest ) {
    try {
        XMLHttp = new XMLHttpRequest();
    } catch(e) {} // we've already checked that this is safe. 
}
else if( window.ActiveXObject ) {
...
}

Since the try is wrapped in an if...else if that checks the type of object to be created, it's safe to swallow the exception.

Answer 4

Even if it's just because nothing can be done with it, it'd still be nice to have comments. However, in ongoing custom/vertical apps with a stable team, sometimes those niceties go away if the reasons are at all obvious in the preceding code.

Answer 5

Looking in my own code, I found a place in my logging code where, after failing to write to a file and failing to write to the event log, it swallows the error as there is no place left to report it. That's one example: there aren't many others.

Answer 6

Maybe because it won't catch but needs to be able to anyway. I can't think of any reason why to avoid some sort of handler, though.