Is there any valid reason to ever ignore a caught

Question

Wow, I just got back a huge project in C# from outsourced developers and while going through my code review my analysis tool revealed bunches of what it considered bad stuff. One of the more discouraging messages was:

Exceptions.DontSwallowErrorsCatchingNonspecificExceptionsRule  : 2106 defects 

The developers assure me they had good reason for all the empty catch blocks, that sometimes the try with empty catch blocks are just there to ignore useless exceptions and keep the application from crashing. I feel this is a cop out and complete BS. Some of the examples I actually looked up were database calls where the record was being saved to the database, and in this case, if an exception was ignored, the user would get back an okay prompt, think everything was okay, and continue on with their work. In reality, their work was never saved. I think this is absolutely the most horrible kind of error. In this case, they are completely wrong in throwing that code in a try with an empty catch block. But my question is, "Is this EVER acceptable in ANY situation?" I think not, but I've been known to be wrong.

Answer 1

Think of it this way - if you are expending the CPU cycles to catch the exception but then swallowing, you are ignoring a potential issue and wasting CPU. As many have said the application should not be throwing that many exceptions unless you have something poorly constructed.

Answer 2

I think that if you have an empty catch block you need to document why it is empty so that the next developer will know. For example on server.transfer a web exception is sometimes thrown. I catch that and comment that we can ignore it because of the transfer call.

Answer 3

Unless your catch code will either

1. Log the exception
2. Repackage the exception into another exception that matches the same abstraction. and throw again
3. Handles the exception the way you see suitable

You can ignore the exception, but at least mention the expected exception in the method docs, so the consumer can expect and handle if necessary

Answer 4

I don't catch exceptions unless I plan to do something about them. Ignoring them isn't doing something about them.

Answer 5

One example of where I'd consider this acceptable is in some non-critical module of a critical application (say, in the sound feedback module of the space shuttle navigation system), for exceptions that should never happen, and cannot be handled more cleanly.

In those cases, you would not want to let that exception propagate and cause the whole application to fail (Sorry guys, no more navigation system, our beeping module crashed, and there was really nothing we could do about it).

Edited to say that in any of these cases, you'd at least want to log the event somewhere.

Answer 6

My feeling is that any empty Catch Block needs a comment.

Possibly it's valid to ignore certain errors, but you need to document your reasons.

Also, you wouldn't want to make it a generic "catch (Exception e) { }".

You should catch only the specific error type that's expected there and is known to be safely ignored.