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
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.
You should never hide Exception. I might hire you anyway, but you wouldn't do that while you worked for me :)
Seriously, though, in Java (for instance) Exceptions are used for certain cases that you may choose to ignore, like FileNotFoundException
(like you did, with a comment). But if you ever catch a type of Exception -- like IOException
-- you cannot just hide it. If the Exception means nothing to you in particular, wrap it in a RuntimeException
and throw it up to the client.
Somewhere along the way, Exception
should be handled, but never hidden.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With