Is there any valid reason to ever ignore a caught

Question

Wow, I just got back a huge project in C# from outsourced developers and while going through my code review my analysis tool revealed bunches of what it considered bad stuff. One of the more discouraging messages was:

Exceptions.DontSwallowErrorsCatchingNonspecificExceptionsRule  : 2106 defects 

The developers assure me they had good reason for all the empty catch blocks, that sometimes the try with empty catch blocks are just there to ignore useless exceptions and keep the application from crashing. I feel this is a cop out and complete BS. Some of the examples I actually looked up were database calls where the record was being saved to the database, and in this case, if an exception was ignored, the user would get back an okay prompt, think everything was okay, and continue on with their work. In reality, their work was never saved. I think this is absolutely the most horrible kind of error. In this case, they are completely wrong in throwing that code in a try with an empty catch block. But my question is, "Is this EVER acceptable in ANY situation?" I think not, but I've been known to be wrong.

Answer 1

I sometimes use a WebControl that is not compulsory for a page to display. If it fails, I don't want to prevent the page from displaying. An example of a non-critical WebControl would be one that displays an advertisement.

However, I do log the error. I just don't rethrow it.

Answer 2

There are certainly circumstances where it's OK to catch a specific exception and do nothing. Here's a trivial example:

    public FileStream OpenFile(string path)
    {
        FileStream f = null;
        try
        {
            f = new FileStream(path, FileMode.Open, FileAccess.ReadWrite);
        }
        catch (FileNotFoundException)
        {
        }
        return f;
    }

You could also write the method this way:

    public FileStream OpenFile(string path)
    {
        FileStream f = null;
        FileInfo fi = new FileInfo(path);
        if (fi.Exists)
        {
            f = new FileStream(path, FileMode.Open, FileAccess.ReadWrite);                
        }
        return f;
    }

In this case, catching the exception is (very) marginally safer, as the file could get deleted between the time you check for its existence and the time you open it.

There are reasons not to do this, sure. In .NET, exceptions are computationally expensive, so you want to avoid anything that throws a lot of them. (In Python, where exceptions are cheap, it's a common idiom to use exceptions to do things like break out of loops.)

But that's ignoring a specific exception. This code:

catch
{
}

is inexcusable.

There's no good reason not to catch the specific typed exception that the code in the try block is going to throw. The first reason that the naive developer gives for catching exceptions irrespective of type, "But I don't know what type of exception might get thrown," is kind of the answer to the question.

If you don't know what type of exception might get thrown, you don't know how your code can fail. If you don't know how your code can fail, you have no basis for assuming that it's OK to just continue processing if it does.

Answer 3

Yes, its acceptable (unavoidable, necessary) in certain circumstances per Maxim's post. That doesnt mean you have to like it. 2106 violations is probably WAY too many and at the least they should have added a comment in the catch block as to why it was ok to swallow this exception.

@Dustin Its bad practice to show any exception details to a public user (stack traces, line numbers, etc). You should probably log the exception and display a generic error.

Answer 4

When it comes to Exceptions, there are always exceptions.

Answer 5

I like to let almost all of my exceptions bubble up to an application handler where they are logged and a generic error message is displayed to the end user. But the caveat here is that there should not be very many exceptions that actually occur. If your application is throwing many exceptions, then there's probably something wrong or something that could have been coded better. For the most part, I try to make sure that my code checks for exceptional cases in advanced because generating exceptions is expensive.

As an aside, outsourcing coding is generally a bad idea. From my experience, usually they are consultants who are only in it for the paycheck and have no stake in the success of the project. Also, you surrender to their -lack of- coding standards (unless you included that in the contract).

Answer 6

That's a really bad thing to be doing.

While there are valid reasons you might want to ignore exceptions - if it's expected in some way, and there's no need to do anything about it - however doing it 2000 times seems like they just want to sweep their exceptions under the rug.

Examples of where it's OK to swallow exceptions might be probing for things... you send off a message to some device or module, but you don't care if it actually gets there.