It's the thought that counts
-
at least they left you a message to let you know what should happen... I've seen them not even try and catch an exception.
-
Add
TODO:to the comment, so Visual Studio can remind you something still needs to be improved. :)Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
at least they left you a message to let you know what should happen... I've seen them not even try and catch an exception.
-
catching and doing nothing is actually worse. It completely hides the fact that anything went wrong. Which uually means you crash somewhere else later.
Well there are lots of cases where catching and doing nothing is ok.
-
Reminds me of
Resume Nextfrom a particularly dark past!Never underestimate the power of human stupidity RAH
-
Reminds me of
Resume Nextfrom a particularly dark past!Never underestimate the power of human stupidity RAH
Reminds me of Resume Next from a particularly dark past! Somewhat, but it's easier to limit the effect of catch-and-ignore to a single statement. Realistically, there are quite a few circumstances in which if an error happens very often the developer should be made aware of it, but beyond that there's no particularly useful action the code can take in response to an error. For example, if a field that affects the display of a control is changed outside the UI thread, it's necessary to use BeginInvoke to let the control update itself. If the BeginInvoke works, great. If it fails because someone closed a window at just the "right" time, so what? It's important to ensure that the code doesn't waste time repeatedly trying to BeginInvoke a control after it's disposed, but otherwise occasional invocation failures should be expected and I really don't see anything useful to be done with them other than ignore them.
-
Reminds me of Resume Next from a particularly dark past! Somewhat, but it's easier to limit the effect of catch-and-ignore to a single statement. Realistically, there are quite a few circumstances in which if an error happens very often the developer should be made aware of it, but beyond that there's no particularly useful action the code can take in response to an error. For example, if a field that affects the display of a control is changed outside the UI thread, it's necessary to use BeginInvoke to let the control update itself. If the BeginInvoke works, great. If it fails because someone closed a window at just the "right" time, so what? It's important to ensure that the code doesn't waste time repeatedly trying to BeginInvoke a control after it's disposed, but otherwise occasional invocation failures should be expected and I really don't see anything useful to be done with them other than ignore them.
supercat9 wrote:
Somewhat, but it's easier to limit the effect of catch-and-ignore to a single statement. Realistically, there are quite a few circumstances in which if an error happens very often the developer should be made aware of it, but beyond that there's no particularly useful action the code can take in response to an error.
In my app, this is the rare case. I think I have one or two and I commented like this catch(Exception e) { // nothing we can do about an error here } Unfortunately, for a lot of people, exception handling consists of catch(...) { } Somewhere they learned this is the proper way to handle exceptions. If it prevents the app from crashing (at this point anyway), that's all you need to do. If you blow up a buffer, hide it and let the next guy deal with it. :mad:
-
supercat9 wrote:
Somewhat, but it's easier to limit the effect of catch-and-ignore to a single statement. Realistically, there are quite a few circumstances in which if an error happens very often the developer should be made aware of it, but beyond that there's no particularly useful action the code can take in response to an error.
In my app, this is the rare case. I think I have one or two and I commented like this catch(Exception e) { // nothing we can do about an error here } Unfortunately, for a lot of people, exception handling consists of catch(...) { } Somewhere they learned this is the proper way to handle exceptions. If it prevents the app from crashing (at this point anyway), that's all you need to do. If you blow up a buffer, hide it and let the next guy deal with it. :mad:
If something like an empty try/catch is discovered in code that I am in charge of (and believe me, I will discover it, thanks to FxCop), I will refuse to accept it for production code. :mad: If an error happens and absolutely no action can or should be taken (a very rare case), then at least the exception has to be logged and there has to be a comment in the code that explains why it's OK to just "swallow" the exception in this special case. This is the very least for good code... Regards Thomas
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software. -
LMAO :laugh:
-
If something like an empty try/catch is discovered in code that I am in charge of (and believe me, I will discover it, thanks to FxCop), I will refuse to accept it for production code. :mad: If an error happens and absolutely no action can or should be taken (a very rare case), then at least the exception has to be logged and there has to be a comment in the code that explains why it's OK to just "swallow" the exception in this special case. This is the very least for good code... Regards Thomas
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.Thomas Weller wrote:
If something like an empty try/catch is discovered in code that I am in charge of (and believe me, I will discover it, thanks to FxCop), I will refuse to accept it for production code. If an error happens and absolutely no action can or should be taken (a very rare case), then at least the exception has to be logged and there has to be a comment in the code that explains why it's OK to just "swallow" the exception in this special case. This is the very least for good code... Regards Thomas
All I can add is AMEN I will confess that in my code above where I "swallowed" the exception was when a thread was ending and his parent had already disappeared. Which in practice, has never happened. I believe that is the only time I have done this. I sent out an email a few years ago telling people to add exception handling (since I throw exceptions) and their response was to add catch (...) {} all over the place. Fortunatley, I log all exceptions at the source.
-
If something like an empty try/catch is discovered in code that I am in charge of (and believe me, I will discover it, thanks to FxCop), I will refuse to accept it for production code. :mad: If an error happens and absolutely no action can or should be taken (a very rare case), then at least the exception has to be logged and there has to be a comment in the code that explains why it's OK to just "swallow" the exception in this special case. This is the very least for good code... Regards Thomas
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.I agree. There are some rare cases where doing nothing is the correct thing to do. A third-party library we use throws an exception if you call Init() more than once, but doesn't actually mess up the state of the library. Our app is multithreaded, so we have an empty catch block there. Mind you, these edge cases are well documented with comments.
Cheers, Vıkram.
Carpe Diem.
-
I agree. There are some rare cases where doing nothing is the correct thing to do. A third-party library we use throws an exception if you call Init() more than once, but doesn't actually mess up the state of the library. Our app is multithreaded, so we have an empty catch block there. Mind you, these edge cases are well documented with comments.
Cheers, Vıkram.
Carpe Diem.
Yes, sometimes is a good reason to use an empty catch. It still only acceptable if it is well documented as to why it was done so that some poor programmer a few years down the road doesn't have to waste time trying to figure out how the exception should really be handled.
Just because the code works, it doesn't mean that it is good code.