Is it okay that I sometimes sink my exceptions?

Asked 2010-01-26T19:56:39.373

I have a best practices question. I realize this is subjective but wanted to ask people smarter than me if this is a common programming practice.

If you have a method of something NON-CRITICAL that you don't want to interfere with the important functioning of your application, is it common to use an error sink like this?

Try 
    'do stuff.  not important if it fails.

Catch ex as exception
    'sink.  do nothing.
End Try

If you were thinking of hiring me and you were reading some of my code and saw this...would you?

Seth

EDIT Wow! Thanks for your answers. I think the consensus is that should never be done or it should be very rare.

I thought I would give you context for this question. First, I have a strong familiarity with the Karl Sequin article and have followed that pattern for years.

But today on the project I was working on, I was working through the change list and was faced with the addition of a simple feature. (If you care to know...it is adding context menu support to a Rich Text Box.)

The attached note said, "if it takes longer than 15 mins...drop it."

So I am faced with adding what is a potentially useful feature but the don't really have the time to test that it won't break working features. For the record, our exception handler for this system DOES have a mechanism for handling and sinking or logging these errors. But what if I was working on a system that did not have a robust error handling system. Would it be okay to add this feature and if an error occurs...nothing is really lost.

That was my thinking. But I have taken your message to heart...that basically this is a bad idea.

Seth

exception

Edit Report

3 Answers

While most people here are actually talking about the developer, I would like to point out another viewpoint of the story.

I admit: I have swallowed exceptions and in every case it was because IMHO the designer of the function screwed up.

"Exceptions" means "exceptions", not failure or error. What I mean is: If the function must acknowledge that the input may not be correct, I expect that the function does NOT use exceptions. My wrath targets particularly "ParseException"s.

If you parse input, you will very likely find unknown/corrupted/inexact input. That is "normal", not an exception. And in this case I find it annoying if the developer of the function throws ParseException if the function couldn't properly parse.

Why ?

The exception breaks the control flow
The exception is slow
Often it doesn't matter anyway because you are initializing with default values.

If you call the parseFunction several thousands or millions(!) of times you are clogging up your log file for exactly nothing.

In contrast my ideal function gives back a class object with status code and message like

StatCode stat = parseXYZ(Reader r);

which can be then be tested.

if (stat.code != OK)  
  //whatever

If in the other way you are experiencing problems which you can't foresee (file not locked, nonsensical argument, illegal thread state) exceptions are excellent.

answered 2010-01-26T20:59:09.843

Personally I see this as being incredibly bad practice.

It is (unfortunately) one of the things I always look for when reviewing code, and the questions I ask when I find empty catch blocks or catch blocks that essentially swallow exceptions are:

At this moment in time are you 100% sure that this exception will never matter?
Are you also 100% certain that any exception caught here in the future will never matter, regardless of how the code base develops?
Even if 1 and two are both true, is it really so hard to put some logging here?

The most important thing for me is the logging - good logging of exceptions, and good tracing of program execution are fundamental to the design of code that can be safely modified over time, and that evolves into a stable system that users have faith in.

Beyond that, a good practise is to only catch specific exceptions, and to let all other exceptions bubble up the stack. Blindly handling exceptions as a way of handling errors is never correct.

answered 2010-01-26T20:04:40.820

I would say "Don't do it" - not like that.

First of all, try refactoring the "noncritical" code so that it doesn't throw an exception.

If you are unable to do that, at the very least don't blindly catch Exception. Only catch the exceptions that you expect it to throw (and log them somewhere!) - anything else is something you need to be made aware of.

answered 2010-01-26T20:03:01.300

Is it okay that I sometimes sink my exceptions?

3 Answers

Your Answer