Is there any valid reason to ever ignore a caught exception

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

Answer 1

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.

Answer 2

I guess from what I gather the best answer is that it can be somewhat acceptable but should be limited. You should try to use another alternative, and if you can't find another alternative, you should know enough about how the code works that you can expect specific exception types and not just use the blanket catch all "Exception". Documentation of the reason why this exception is ignored should be included in the form of an understandable comment.

Answer 3

in critical code, probably not, because the state of the program must always be exactly defined. like your database call example.

in noncritical code, sure, we do it too (we just display caught exceptions in a message box and keep running). maybe a plugin or module is failing, but the main program isn't affected. maybe a lexical_cast failed and there's a text glitch rendered to the screen. No need to halt the process.

Answer 4

I sometimes use a WebControl that is not compulsory for a page to display. If it fails, I don't want to prevent the page from displaying. An example of a non-critical WebControl would be one that displays an advertisement.

However, I do log the error. I just don't rethrow it.

Answer 5

I think the original question has been well answered, but one thing I'd like to add is that if you think these outsourced/contracted developers produced poor quality work, you should make sure the right people at your company know about it.

There may be a chance that it can be sent back for rework, that payment can be partially withheld, or that the same firm won't be used again. If your company uses contractors again, they might find a way to build quality requirements into the agreements, assuming that's not alredy there.

If this was in-house work, there would be consequences to the team/individual that produced substandard work. Maybe that would just mean that they have to work nights and weekends to fix it, but they'd be on the hook for it one way or another. The same should apply to contractors, possibly even more so.

Just be careful to explain your position professionally and with a focus on what's best for the company/product. You don't want it to seem like you're just complaining, or that you have some kind of political objection to outsourcing. Don't make it about you. Make it about cost, time to market, customer satisfaction, etc. You know, all those things that management types care about.

Answer 6

I like to let almost all of my exceptions bubble up to an application handler where they are logged and a generic error message is displayed to the end user. But the caveat here is that there should not be very many exceptions that actually occur. If your application is throwing many exceptions, then there's probably something wrong or something that could have been coded better. For the most part, I try to make sure that my code checks for exceptional cases in advanced because generating exceptions is expensive.

As an aside, outsourcing coding is generally a bad idea. From my experience, usually they are consultants who are only in it for the paycheck and have no stake in the success of the project. Also, you surrender to their -lack of- coding standards (unless you included that in the contract).