Sigh, it's the client proxy that throws the exception.
We have setup the usual universal error handler implementing the IErrorHandler interface, all good I figured.
The ProvideFault implementation is strait forward, if any exception occurs, wrap it up in a FaultException and return that to the client. I believed that this was it, no faulted channels on my shift and client was happy.
The problem we ran into was the implementation of the ProvideFault. The symptoms was that, when ever a SecurityAccessDeniedException was thrown, the client would catch that exception and show a localized message to the enduser, except the client never got the SecurityAccessDeniedException, it got an untyped FaultException!.
The reason why is actually obvious, if the exception thrown by the service is already an exception derived from the CommunicationException aka a FaultException, the ProvideFault should of course not wrap that fault up into yet another FaultException, it should simply just return from the ProvideFault and let the faultexception travel.
So the implementation must have the following check:
public void ProvideFault(Exception error, System.ServiceModel.Channels.MessageVersion version, ref System.ServiceModel.Channels.Message fault)
{
if (error is FaultException)
return;
this way the faultexception is propagated to the client proxy and then the client proxy will turn the FaultException into the SecurityAccessDeniedException and then re throw it.
My theory is that all of Scottish cuisine is based on a dare.
-- Mike Myers
4:43:54 PM 
|
