Strange Exception Handling dummy instruction

Question

At my work I have to maintain some C# projects. The original developer is not around anymore. Lately I noticed some strange code mostly found in situations like this:

try
{
    //some Code
}
catch
{
    0.ToString();
}

What is the 0.ToString() for? Most of the code was written under stress, so I can think of two possibilities:

• It's a placeholder (like //TODO), for which can be searched to know where do you have to fix some stuff.
• It's to avoid warnings when compiling for empty catch clauses.

Is there any other usecase or sense in that? Is this good/bad coding style or practise? Since this instruction does nothing, will it have some small impact on performance or will the compiler just remove it? Which are better ways to do something like

Answer 1

As the comments suggest, the code sample contains one strange thing and one bad thing. The

0.ToString();

is almost definitely so that there is a line of code where a debugger can place a breakpoint. This is one of the stranger lines I've seen used for this purpose. It's likely that this line was committed unintentionally after a debugging session.

Separate from that is the empty catch block, which is generally not a good idea. Ryan Gates gives a fine answer for that, so I'm not going to expand on that point. But the ironic thing is that if there were a proper catch block, there would be a line of code to place a breakpoint on.

Answer 2

No there is not another usecase or sensible reason for doing this. It is a bad coding practice. Your code should not catch any exception that it cannot handle.

The best path forward is to remove it. When an exception is thrown, you need to understand that usecase. Then and only then can you add the appropriate checks and/or specific exception handling code.

The code in question is an example of swallowing the exception, which is hazardous to your health.