Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

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.

share|improve this question

marked as duplicate by gnat, Kilian Foth, Bart van Ingen Schenau, amon, psr Feb 25 '14 at 18:26

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Very related:… – pdr Feb 19 '14 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. – Jeff Bowman Feb 19 '14 at 23:57
up vote 34 down vote accepted

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

share|improve this answer
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. – Michael Shopsin Feb 24 '14 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.

share|improve this answer

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