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

Yes, it is common, but in general it shouldn’t be done.

There are exceptions like OutOfMemoryException which are better not caught, unless you catch them to attempt to terminate your application gracefully.

In the majority of cases, swallowing System.Exception or System.SystemException will inevitably hide further run-time problems.