Should database insertions, updates and deletions be wrapped in try/catch?

Question

I always use a try catch when i am dealing with database related operations for eg.

try
{
 DataContext.AddtoObjectname(obj);
 DataContext.SaveChanges();
}
catch(Exception e)
{
 throw new Exception("Problems adding object" + e);
}

But I read about try/catch affecting performance here -
http://stackoverflow.com/questions/1308432/do-try-catch-blocks-hurt-performance-when-exceptions-are-not-thrown
So should I add try catch for something I am doing above or should i opt otherwise.Thanks for your help.

Answer 1

It depends. If you only intended on re-throwing the exception, there is no point to have it in a try catch. You're adding code without providing any real value. If you are going to do something with the exception, logging it, check for an specific type etc., that is different, because you intend on acting on the unexpected behavior.

But I read about try/catch affecting performance..

Try catch isn't what really affects performance, its creating the exception that is the "expensive" operation. Really in the big scope of things it's not that bad, and you shouldn't avoid exceptions because of the "expense".

On a related note, if you do a try catch, unless you need to don't create a new exception if you can avoid it. Just re-throw the old exception.

Answer 2

Try/Catch statements themselves don't significantly affect performance, but throwing and catching lots of exceptions might.

In general, you want to make sure that you catch only relevant exceptions - otherwise you might be masking a bug in your application. In this case DataException or UpdateException are probably good candidates as they are the exceptions that will be thrown if something goes wrong in SaveChanges.

It seems that you're catching the exception to add your own additional information to it. In that case, it's always best to preserve the original exception as the Inner Exception.

throw new Exception("Problems adding object" + e, e);

I would also advise creating your own application specific exception type for this purpose.

Answer 3

• Only catch what you can handle. If you can't handle the error and gracefully recover, let the exception bubble up to some higher level that can handle it. If you want to log the exception where it happens (reasonable) then log it and re-throw the same exception if you can't recover.

• As a general rule, never catch a generic exception. Instead, explicitly specify the exceptions: catch (SQLException e) instead of catch (Exception e)

• If you throw an exception from a catch block, be sure to put the caught exception into the new one's inner exception.

• Don't throw an Exception, be more specific. If the framework doesn't already have an exception for what you need, make one.

Answer 4

Yes this is what try/catch for. Losing control and having risk to bring your database to inconsistent state cost more than try/catch overhead. if there is an exception there is no "cheap" way to deal with generally speaking....