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 -
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.

Yes,otherwise how would u tell client of the status of that operation. — Srinivas Reddy Thatiparthy, Jun 23 '10 at 16:27
How does catching all exceptions and then throwing a new one help? — Brendan Long, Jun 23 '10 at 16:28

score 4 · Accepted Answer · answered Jun 23 '10 at 16:32

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.

You should never throw `Exception` at all. FxCop blocks this, and for good reason. — Craig Stuntz, Jun 23 '10 at 16:57

score 2 · Answer 2 · answered Jun 23 '10 at 16:28

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.

score 2 · Answer 3 · answered Jun 23 '10 at 16:40

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.

score 0 · Answer 4 · answered Jun 23 '10 at 16:48

0

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....

answered Jun 23 '10 at 16:48

Boppity Bop

9,613
13
72
151

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

4 Answers4