Is it ever okay to catch an exception and do nothing? [closed]

Closed. This question is opinion-based. It is not currently accepting answ开发者_如何学编程ers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

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?

---

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.

---

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.

---

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.

---

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.

---

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.

---

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.