What is the advantage of wrapping exceptions [duplicate]

Question

It's very common in .NET for an exception to be wrapped in several layers of "outer exceptions" which give marginally more contextual data. For example, in EF if your update fails, you get exceptions wrapped similar to this:

• EntityException
• DbUpdateException
• SqlException

The data I need to understand what failed is almost always in the SqlException, so what's the advantage to the other two? What if I was using EF inside a custom library, should I wrap this exception with one of my own? Like MyCustomLibraryException: Could not update the data. See inner exception for details.

Answer 1

to hide what the core cause was in places where it doesn't matter

the top level only needs to know that a storage exception occurred instead of an SQLException, which may not happen if you decide to migrate to a non-sql data store

not wrapping also leaks the abstraction and requires reimplementation of the top level when doing a migration of a lower level which will then use different exceptions

Answer 2

A compelling principle behind error handling is to handle the error at the layer best suited to deal with the error. Handling an error can involve retrying the operation, signaling the user, or just plain rolling over and dying.

Frequently, this means that error handling is taken care of fairly high up in the application stack as you don't want to have duplicate error handling code scattered all over your application. Likewise, lower layers won't have the necessary information in order to figure out what sort of corrective action is appropriate.

But this presents a problem when your error handling is fairly high up in the stack and the error occurs at a fairly low point in the stack. What you call "marginally more contextual data" is information that the lower level is providing to the calling level in order to give the calling level a better shot at taking corrective action instead of rolling over and dying.

In your specific case, it sounds like you need additional error handling closer to the database call so that you can take more appropriate corrective action.