Reputation: 67243
I am using Enterprise Library 5.0, a tool to manage cross-cutting concerns like logging from.
One of the options the tool gives me is to "replace" an exception. I can see the purpose of wrap in some cases, but why would I ever want to completely replace the exception?
Thanks
Upvotes: 4
Views: 158
Reputation: 3207
There are lots of reasons to replace an error and like the other answers here security is one of the them but not the only one. Sometimes you may just want to improve your API so that the different layers of your application are responding to things that make sense. For instance I wouldn't expect to see the UI of a desktop application catching a SQL exception, parsing that exception and then telling the user that a duplicate key was found in the database. Instead you may have a custom Exception called DuplicateRecordException that is thrown from the data access layer. This exception might include the original exception as the InnerException but now you have an exception coming out of the DAL that makes sense from a UI layer point of view.
Upvotes: 2
Reputation: 942070
I'm guessing you are talking about the Exception Handling Block? I studied it for a while, trying to find the point behind it. Admittedly I still don't really get it, but that's a professional liability. As far as I can tell, it gives IT staff some measure of control over the way exceptions are reported and dealt with.
Which is relevant in an enterprisey setting where the departmental gap between the people that create exceptions (software engineers) and the people that have to deal with them (IT staff and users) can be difficult to bridge. Code crashing with an impenetrable exception message is all too common, getting them fixed with lots of middle management layers in between can be quite difficult and time-consuming. In this kind of scenario, being able to improve the diagnostic and help the user avoid to make the same mistake, instead of having to slay the enterprise dragon, makes a lot of sense.
Upvotes: 1
Reputation: 4939
What if the original exception contained sensitive proprietary data, or similar, and you just wanted to replace it wholesale? That might be one occasion when wrapping wasn't appropriate, as what you want to do is strip out the sensitive parts but keep a core set of technical information. I've had similar issues in the past with financial apps, where you don't want to send complete in-house logs to a vendor, for example. In that case it was some effort to explicitly separate sensitive and non-sensitive error handling, to different log sinks.
Upvotes: 4
Reputation: 273574
I don't know if this applies but WCF also has a feature like that. Passing all error information along, over comm boundaries, sometimes is a security risk.
Upvotes: 1