Don’t Swallow Exceptions – Ever

Is there any good reason to do this? I say no. It makes your code run slower, and with tricky to debug errors. Throw exceptions early – then they will be dealt with during development, rather than in production.

We found today that we had some errors in some of our data access code that was pulling data out of a datarow and into an object.

We essentially had code that performed the following:

try
{
   object data = dataRow[ColumnName];
   return data;
}
catch (Exception ex)
{
   Logger.Error(string.Format("Could not retrieve Column value with column name - {0}\n.{1}", ColumnName, ex));
}

This led to our integration tests passing, as they are not able to see that an exception is raised, and the stored procedure needs to be updated with the relevant Column.

Far better would be:

catch (Exception ex)
{
   Logger.Error(string.Format("Could not retrieve Column value with column name - {0}\n.{1}", ColumnName, ex));
   throw;
}

This logs the exception as per the original, but also throws the exception, and voila, our integration test will catch that.

And yes, the fact that we are using Stored Procedures is not ideal either.