I am reading the EntLib online documentation in section "When to Use the Exception Handling Application Block" and I am interested to learned from everyone why the documentation recommends the use of "Wrap Handler" when crossing tiers.
In that Figure 1 of that section, it is between the Data Access Layer and the Business Layer. Let take this as an example: if one wants to replace say SqlException in a particular implementation of the DAL (the other one could be by Oracle) by a application
specific exception. If one uses wrap handler, my reading tells me that the original exception, the SqlException, is being carried along in the new exception as the inner exception.
My question is: When the new exception is being handled on the Business Tier (crossing App Domain boundary), the deserialization will fail unless the business tier can deserialize not only the exception but also the inner exception. In order to deserialize
the inner exception, it would require the assembly supporting it. Is this logic correct? I have encountered situations when the DAL components are ServicedComponent and if I embedded say SqlException in an exception, let say InvalidOperationException, I've
thrown, I need to include the assembly in which CLR can find the SqlException. Otherwise I get the SerializationException.
I guess if one wants to avoid this, one should then use the replace handler but that is not recommended in that diagram. Can someone offer some advice in this regard?
On a philosophical question: Should a cross-tier exception embedded the originally caught exception. If the answer is affirmative, wouldn't that expose the implementation details of that tier to the next? For example, if one replaces the DAL tier with one using
Oracle, the business tier then needs to know how to deserialize the Oracle exception. But your DAL interface makes not mention about Oracle or SqlServer and in fact it only specifies implementation agnostic exception.