Is there a situation when it's appropriate to use empty catch block? [duplicate]

Question

Possible Duplicates:
Why are empty catch blocks a bad idea?
Is there any valid reason to ever ignore a caught exception

Do you know any situations when an empty catch block is not the absolute evil?

try
{
    ...
    // What and When?
    ...
}
catch { }

Graeco

Empty catch blocks are always evil, except when used with empty try blocks. – Elegy

Empty catch blocks are not always evil. Empty all-match catch blocks are always evil. – Monaco

@Frédéric Hamidi, your comment accepted as an answer – Graeco

Answer 1

There are a lot of questions on this, try to look at:

Why are empty catch blocks a bad idea?

From that post's accepted answer:

Usually empty try-catch is a bad idea because you are silently swallowing an error condition and then continuing execution. Occasionally this may be the right thing to do, but often it's a sign that a developer saw an exception, didn't know what to do about it, and so used an empty catch to silence the problem.

It's the programming equivalent of putting black tape over an engine warning light.

Volauvent

Answer 2

I would say you should at least be providing some sort of comment or logged message indicating that what you put in the try {} threw an exception and this is why you aren't doing anything.

Diverting

Answer 3

Take a look at this, it basically breaks down the kind of exceptions you could encounter into four categories, none of which should be handled by an empty catch block.

Perfectible

Yet... I can show you perfectly reasonable code that contains an empty catch block. An empty catch block does not mean "do nothing". – Monaco

No, an empty catch block means, something went wrong, I don't know what, but just ignore it and continue. VB 6 had a "On Error Resumed Next" command that automatically does that for you, and it was a delight to debug code peppered with it. – Perfectible

What should be done in the catch block for the vexing exception which is thrown by Control.BeginInvoke if the control gets disposed before the method completes, and if the only reason for calling the method was to let the control know that it should redraw itself? I'd hardly consider such an occurrence as being worth logging. To be sure, the empty catch block does indicate a coding defect, but the defect is the lack of a TryBeginInvoke method. – Physiognomy

Answer 4

I used it for some self-written libraries where i need some kind of bool TrySomething(out object) function or object TrySomething() where the underlying call doesn't provide any other mechanism as an exception. In this case i use an empty catch block and return false or null (depending on the function signature).

Example to prove empty catch block

public bool TrySomething(out object destination)
{
    try
    {
        destination = DoSomething();
        return true;
    }
    catch
    {}

    return false;
}

Stripling

But do we speak in that case still about an empty catch? You are setting a return value in that case. – Dissect

@ChristopheLambrechts: Added example to prove that the catch block would be empty. – Stripling

In that case I would place the return false; statement in the catch block. – Dissect

This is a typical vexing exception. See Vexing exceptions | Fabulous Adventures In Coding for details. – Opaque

Answer 5

Axiom:

Empty catch blocks are absolute evil

Don't try to find your way around this. Just by trying to find cases where they aren't absolute evil means you're wasting precious brain cycles. Don't try to find a pattern here, thinking "hmm, should I put an empty catch block here?"

If you stumble upon an empty catch block in somebody's code, you've just stumbled upon technical debt. Fix it. Even just by adding one logging statement inside an empty catch block, you'll make this world a better place.

Contrive