Friday, March 27. 2009
Wcf Exception Shielding - Unexpected FaultContracts
So you've got Wcf Exception Shielding in place. All is well and the Enterprise Library Exception Handling Application Block takes care of those nasty exception details that you don't want your site visitors to know about... But have you ever had the urge to do more than just property mapping between exceptions and FaultContract? I know I have 
There is a way to do this and it is actually quite simple to realize. You just have to create your own custom IExceptionHandler. But let's start with a bit of configuration. By default you would have an Exception Policy named "WCF Exception Shielding". Like so:
<exceptionHandling>
<exceptionPolicies>
<add name="WCF Exception Shielding" />
</exceptionPolicies>
</exceptionHandling>
This policy handles specific Exception types and for each of those it will pass the exception through a chain of IExceptionHandlers. The last of these would normally be Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.FaultContractExceptionHandler. For instance:
<exceptionTypes>
<add type="System.DivideByZeroException, mscorlib"
postHandlingAction="ThrowNewException" name="DivideByZeroException">
<exceptionHandlers>
<add exceptionMessage="Dividing by zero is not allowed."
faultContractType="DivideByZeroFault, MyDll"
type="FaultContractExceptionHandler, ExceptionHandling.WCF"
name="Fault Contract Exception Handler">
<mappings>
<add source="Guid" name="Id" />
<add source="Message" name="Message" />
</mappings>
</add>
</exceptionHandlers>
</add>
</exceptionTypes>
Now what if your FaultContract would need additional data, that you can't just map from the Exception properties? For example:
- you might need the Message property of the InnerException;
- you need data that was logged to a database when the original exception got thrown.
To make this possible, just create your own IExceptionHandler that will be used instead of the provided FaultContractExceptionHandler. There are two things to keep in mind when you do this. First of all you should always set the postHandlingAction to ThrowNewException. Second, you should let your IExceptionHandler return a specific Exception type: FaultContractWrapperException. Read More
There is a way to do this and it is actually quite simple to realize. You just have to create your own custom IExceptionHandler. But let's start with a bit of configuration. By default you would have an Exception Policy named "WCF Exception Shielding". Like so:
<exceptionHandling>
<exceptionPolicies>
<add name="WCF Exception Shielding" />
</exceptionPolicies>
</exceptionHandling>
This policy handles specific Exception types and for each of those it will pass the exception through a chain of IExceptionHandlers. The last of these would normally be Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.FaultContractExceptionHandler. For instance:
<exceptionTypes>
<add type="System.DivideByZeroException, mscorlib"
postHandlingAction="ThrowNewException" name="DivideByZeroException">
<exceptionHandlers>
<add exceptionMessage="Dividing by zero is not allowed."
faultContractType="DivideByZeroFault, MyDll"
type="FaultContractExceptionHandler, ExceptionHandling.WCF"
name="Fault Contract Exception Handler">
<mappings>
<add source="Guid" name="Id" />
<add source="Message" name="Message" />
</mappings>
</add>
</exceptionHandlers>
</add>
</exceptionTypes>
Now what if your FaultContract would need additional data, that you can't just map from the Exception properties? For example:
- you might need the Message property of the InnerException;
- you need data that was logged to a database when the original exception got thrown.
To make this possible, just create your own IExceptionHandler that will be used instead of the provided FaultContractExceptionHandler. There are two things to keep in mind when you do this. First of all you should always set the postHandlingAction to ThrowNewException. Second, you should let your IExceptionHandler return a specific Exception type: FaultContractWrapperException. Read More
