Comments on: Simplifying WCF: Using Exceptions as Faults

By: Tony Carl

Tony Carl — Mon, 25 Jul 2011 22:09:56 +0000

Not sure if anyone has a better solution for Fault Exceptions (see Bunty Singh post above). What I did was change replace the FileNotFoundException catch to just a generic Exception catch when it tries to read from the serializer in ExceptionMarshallingMessageInspector.cs. The code looks like this now:

NetDataContractSerializer serializer = new NetDataContractSerializer();
try
{
return serializer.ReadObject(reader);
}
catch (SerializationException)
{
// Serializer was unable to find assembly where exception is defined
return null;
}

Seems a little hackish to ignore all SerializationExceptions. With this change, I can successfully catch FaultException.

By: Hashname

Hashname — Wed, 15 Jun 2011 11:49:04 +0000

Awesome!!!
Still I’m kind of freaked out about the extent of coding required to get basic stuff like exception handling to work seamlessly in WCF.

By: Getting something better than “Server not found.” from WCF in Silverlight « Matt Duffield

Wed, 06 Apr 2011 14:18:08 +0000

[…] I find very instrumental in dealing with exceptions in WCF. Oleg Sych wrote an excellent article, Simplifying WCF: Using Exceptions as Faults, back in 2008 that I believe is still very pertinent for us today. His solutions is very similar to […]

By: Harvo Jones

Harvo Jones — Tue, 27 Jul 2010 19:38:01 +0000

Oleg, very good stuff. Thanks for helping us navigate the intricacies of WCF configuration.

By: Unwrap WCF FaultException « maonet technotes

Unwrap WCF FaultException « maonet technotes — Wed, 10 Feb 2010 17:04:56 +0000

[…] other faultexception, so I don’t need investigating ExceptionMarshallingBehavior described here and […]

By: A debug only WCF Exception problem « maonet technotes

A debug only WCF Exception problem « maonet technotes — Thu, 31 Dec 2009 16:13:26 +0000

[…] http://www.olegsych.com/2008/07/simplifying-wcf-using-exceptions-as-faults/ […]

By: Wout

Wout — Wed, 16 Dec 2009 21:09:08 +0000

Hi, thanks for the insights! I couldn’t get the IErrorHandler to work still, but I did find a sneaky workaround. I’ve just written a post about the details (seems bl##dy .NET BCL bug): http://www.woutware.com/blog/post/Implementing-IErrorHandler-and-working-around-SerializationException.aspx

- Wout

By: Mike V

Mike V — Tue, 10 Nov 2009 21:41:29 +0000

FYI, your zip file appears to be missing the file “Examples.cs”.

By: Bunty Singh

Bunty Singh — Wed, 01 Apr 2009 09:37:17 +0000

Firstly thanks for your wonderful explanation.

One wierd thing that I have noticed was, though exceptions cannot be serialized using DataContractSerializer hance the NetDataContractSerializer. However is the client throws FaulException instead of the exception i.e. instead of client throwing say ArgumentNullException if it throws FaultException, the error handler will be bypassed and the exception get serialized using the normal DataContractSerializer without any serialization exception. And at the client end you would IClientMessageInspector would throw serialization exception.

By: Michael Carr

Michael Carr — Fri, 13 Mar 2009 18:10:30 +0000

I believe I’ve isolated the problem with BasicHttpBinding. The two bindings (NetTcpBinding vs BasicHttpBinding) seem to use different Fault objects when serializing faults. The NetTcpBinding uses a Fault that serializes out with a “Details” tag, while the BasicHttpBinding uses a Fault that serializes out with a “details” tag. This causes the ExceptionMarshallingMessageInspector to break when trying to locate the Details element. I modified the code as follows to fix this problem:

ExceptionMarshallingMessageInspector.cs:

40: const string detailElementName = “detail”;

47: if (reader.NodeType == XmlNodeType.Element && reader.LocalName.ToLower() == detailElementName)

54: if (reader.NodeType != XmlNodeType.Element || reader.LocalName.ToLower() != detailElementName)