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.

  • Very related: programmers.stackexchange.com/questions/132612/…
    – pdr
    Commented Feb 19, 2014 at 14:47
  • Should you have a copy of Josh Bloch's Effective Java Second Edition laying around, item 61 ("Throw exceptions appropriate to the abstraction") describes this well. Commented Feb 19, 2014 at 23:57

2 Answers 2


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

  • Upper layers of the program probably just care if the data was retrieved, not why the retrieval failed. Overly specific exceptions force the higher levels of the program to duplicate error handling when the effect of the exception is more important than the reason. Commented Feb 24, 2014 at 15:32

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.