Is it okay that I sometimes sink my exceptions?

Question

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

Answer 1

Java brought to the fore the need to program with Exceptions. I've found Java tends to willingly throw Exceptions, which is annoying because you have to catch them if you don't want your app to crash. Unfortunately, Exceptions in Java are a fairly heavy feature.

I learnt about effectively using exceptions in Icon. Icon has this neat thing called 'Failure'. If an expression doesn't have a value it can return, it will instead Fail. This functions like a miniature exception only instead of the try {} catch {} notation, Failure is handled by language elements directly, such as if and while.

IMO, that is how Exceptions should work in Java... but unfortunately, they don't. Instead, you end up writing defensive code to prevent Exceptions rather than handling them easily and naturally. Silently swallowing a particular Exception because it's reasonably rare and much more elegant than preventing it I would regard as A Useful Trick. But it's the kind of thing that responds to "You must know the rules before you can break them". In other words, don't do it too often.

I wish more languages supported the Success/Failure model found in Icon.

Answer 2

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.

Answer 3

If this is a good thing or not depends on the language and how expensive exceptions are. You still shouldn't catch ALL exceptions, but, for example, in Python the following is a common idiom:

d={}
for i in theList:
  try:
    d[i] += 1
  except KeyError:
    d[1] = 1

And that's the fastest way to do default insertion. You'd do the same thing for a DivisionByZeroError, or any number of other exceptions. And the definition of a bunch of flow control constructs boils down to raise StopIteration

Answer 4

Best practices says that you shouldn' do this. What is so unimportant that you wouldn't want to know that an error occurred? I don't think I've ever encountered this.

I'd either not use the try catch structure or I refactor the code in to a method that returns a boolean so that I at least can identify if it succeeded or not...

That's my thought...

Update: There are times where you might need to sink an exception. In these cases, I'd identify which exceptions might be candidates for this and then catch those specific exception. But this is far from catching Exception which could be any thing, such as the aforementioned OutOfMemoryException. In short, I'd only catch specific exceptions with the intent to ignore it.

Answer 5

It's common, but it's best to avoid it. At the very least you should log the exception somewhere.

Also, avoid using exceptions for flow control. Your code should be written to handle all likely cases without resorting to exceptions. Aside from performance increases, this method also tells you that when an exception happens, it's worth your attention.

Answer 6

Best Practices for Handling Exceptions (MSDN):

According to them you can either

Do something with the error or ignore it.

It's up to you and your team to decide I guess.