Question

Is it always a bad programming technique to leave a catch block empty when using a try-catch block?

In cases where I am expecting an exception, for example, I am reading 10 values from a file…and converting each value into a String. There is a possibility that one of the 10 values can be a null, but I don’t want to stop my execution at that point and rather continue (obvious use of try catch)

A lame example of what I am trying:

String _text = textReader.ReadLine(); //Assuming this RETURNS a NULL value
try {  
      String _check = _text.ToString(); 
      //Do something with _check, but it should not be NULL
    }
catch (Exception) 
    { //Do Nothing }

At this point, when I catch an exception:

1. I don’t want to log this. Since I am expecting a buggy value.

2. I don’t want to re-throw the exception up the call-stack.

3. I want to simply continue with my execution

Under these cases, is it acceptable to leave the catch empty? Or is this a complete NO-NO and there is a better way to handle this?

I presume this can be a community wiki since it also deals with programming techniques.

– Ivar

Answer 1

I assume that you mean

 _text.ToString()

and you’re concerned about the case when _text may be null?

I don’t like your use of exceptions in this case. Put yourself in the mind of someone needing to maintain this code. They see:

catch (Exception) {  }

Can they really deduce that all this is doing is catching the Null case? They have to consider what other Exceptions might be thrown. At the very least this raises uncertainty in the maintainer’s mind.

Why could you not code:

 if ( _text != null ) {
      String _check = _nullValue.ToString();
 }

This says exactly what you mean.

But taking this further, what does getting a value of NULL mean? You’re reading a file that may have 10 values in it. I’m guessing that maybe blank line gives a null for you?

What do intend if you get:

 1
 2
 <blank line>
 4
 ...
 10  

So that’s 9 good values and a blank line. What will you do if instead you get 10 good values and a blank line? 11 good values? 11 good values and a blank line?

My point is that silently ignoring oddities in user input is often a bad idea. It’s quite likely that some of the cases above are actually typos. By warning in some of these cases you may be very helpful to the user. This implies that probably most odditities in input need at least some kind of count, if not an actual immediate error log.

You might, for example, emit a message at the end

Your file contained 13 lines, two lines were blank. We processed 10 valid values and ignored one.

At the very leasyt for debugging purposes you might have trace statements in the error paths.

Summary: completely ignoring Exceptions is rarely the right thing to do.