17
try
{

    CallMethod()

}
catch { }

From my experience, I generally wouldn't do this.

But if I had a piece of functionality that say, uses a 3rd party COM assembly which occasionally fails and it's actually not important enough to log it cause I'll be calling it again in a couple of seconds anyway, is it okay to do this?

If not, what alternative do I have?

Diskdrive
  • 18,107
  • 27
  • 101
  • 167
  • Related topic worth reading: https://softwareengineering.stackexchange.com/questions/16807/is-it-ever-ok-to-have-an-empty-catch-statement – aug Aug 23 '18 at 21:03

6 Answers6

19

Sure there are times, but they should be very intentional.

Your best practice in those cases is to leave a comment in the catch block to make sure it's clear that it's intentionally blank.

STW
  • 44,917
  • 17
  • 105
  • 161
  • 3
    +1 for leaving a comment in the exception block, to make people realize there is a reason you are purposely ignoring an exception. – Nix Apr 28 '11 at 02:16
  • 2
    And since I've seen it a few times, ideally it isn't a comment that says `// do nothing`... say why you should be doing nothing... – aug Aug 23 '18 at 21:01
11

An empty catch block like the one shown shouldn't be used.

For example, the code in your question would also catch OutOfMemoryException, StackOverflowException, ExecutionEngineException, AccessViolationException and ThreadAbortException (though the latter would be rethrown at the end of the catch block). It would even catch objects that don't derive from System.Exception (rare, but possible in managed C++ and JavaScript...in the CLR, any object can be 'thrown', but C# limits you to Exception-derived types).

If, in your example, you're using a 3rd party COM object that occasionally fails and you don't care about these failure, you should instead catch (COMException) {}, so that other more serious failures 'bubble up' and can be logged and/or fixed.

It's important to catch only those exceptions that you can actually do something about (in this case, you're explicitly choosing to do nothing about exceptions arising from CallMethod(), and I agree that a comment should be added to indicate this design decision). By following that guidance, you're preventing other bugs and problems in either the code or the runtime environment from going unnoticed.

M. Shawn Dillon
  • 1,208
  • 11
  • 7
  • Thanks, I like that answer. As an additional note, what would you suggest for a 3rd party managed library which you have no access to or control over? – Diskdrive Apr 28 '11 at 02:11
  • Actually exceptions like OutOfMemoryException, AccessViolationException etc. are not handled by try..catch as they mean corrupted state. Read more: http://stackoverflow.com/questions/3469368/how-to-handle-accessviolationexception – Wojciech Kulik Jan 30 '16 at 20:48
3

I would at least log the occurrence with a "Warning" or lower level in the catch block, so that you can always enable logging and see what's happening if you need too.

Anthony Accioly
  • 21,918
  • 9
  • 70
  • 118
  • Say, your COM service start failing every time for some unknown reason, wouldn't it be useful to be able to enable logging and check the exception in the future? – Anthony Accioly Apr 28 '11 at 02:03
  • I thought about logging it, but to tell you the truth, it probably does fail about 10% of the time. I feel logging it will just overwhelm the log with lots of useless entries. I think maybe I'll put a counter in there and maybe if it fails 100 times in a row or something, I'll log it as a problem... – Diskdrive Apr 28 '11 at 02:08
  • Yeah. I would go even further and log every exception at a low level such as "FINE", and log the "100 times in a row" event at a "ERROR" or "WARNING" level. Then disable "FINE" level in production. Guess I had my share of troubles with expect Exceptions going wild. – Anthony Accioly Apr 28 '11 at 02:16
2

Generally, you want to design your code to handle errors in some way.

That said, if you're willing to handle the consequences of failing silently, go ahead.

Matt Kline
  • 10,149
  • 7
  • 50
  • 87
0

Your third party component fails. How does it fail? Does it fail in a consistently predictable (while erratic in timing) way? Do you get a TakingABreakException? If so, catch the predictable exception, do whatever you will with it, document it, etc., and let everything else bubble up.

Do not catch everything if you can catch the one thing you know happens from time to time. What might be breaking now might not be the third party component, or it might be behaving badly because of an input you might have used. These things should not get swallowed.

Anthony Pegram
  • 123,721
  • 27
  • 225
  • 246
  • The problem with that is that under no circumstances do I want this assembly failing from actually affecting the rest of my application. If I handle TakingABreakException, what if there is another type of exception that I haven't catered for, if I let it float to the surface, I will get an unwanted error message. – Diskdrive Apr 28 '11 at 01:58
  • Under no circumstances *ever*? Then you document that. But I would rather hope that the failures, while not preventable, would have a predictable signature to them. But as always, it's your application, we're just armchair quarterbacks trying to offer sage advice to you and other people with similar concerns. – Anthony Pegram Apr 28 '11 at 02:08
  • Thanks, yeah it's a weird situation. The COM assembly relies on network resources (AD). Oh and perhaps the orbit of Saturn and Jupiter to align. I could perhaps capture a few scenarios but would not be confident enough to say I've captured all possibiltiies – Diskdrive Apr 28 '11 at 02:17
0

I believe it is always a good idea to catch an exception, especially the most specific exception if you know what it is. I have run into countless bugs that were never caught because, the code ran straight through the catch because it was left empty or someone put a return in there.

Xaisoft
  • 45,655
  • 87
  • 279
  • 432