Two-way WCF service operation returns no reply instead of an exception.

Question

I have two different WCF services doing mostly your basic CRUD operations. For both services, regardless of the client, if the service throws an exception the exception will not be returned to the client. In fact, the only way I can see the actual exception is to turn on tracing in the services and view the trace file.

This is true regardless of the exception being thrown. For example, if I send in a string value with a length greater than that allowed by my service's binding configuration, it will generate a NetDispatcherFaultException exception with the following message, as expected:

The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:newItem. The InnerException message was 'There was an error deserializing the object of type Organization.Division.Application.Service.AddNewItem. The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 20157.'.

The problem is that this exception is not returned by the service, instead, the service throws an ArgumentNullException with the exception message:

Value cannot be null.
Parameter name: message

...and my client just gives me this error (this is true whether my client is an ASP.NET web page, the WCF Test Client, or others):

Failed to invoke the service. Possible causes: The service is offline or inaccessible; the client-side configuration does not match the proxy; the existing proxy is invalid. Refer to the stack trace for more detail. You can try to recover by starting a new proxy, restoring to default configuration, or refreshing the service.
Error Details:
An error occurred while receiving the HTTP response to http://localhost/Services/MyAwesomeS3rv1c3/DoSomethingGrrreat.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

When I view the service trace, I also see this warning: The Request/Reply operation AddNewItem has no Reply Message.

I assume I'm doing something systematically wrong, as this happens regardless of the underlying exception being thrown, on multiple services, and multiple methods for each service. I just cannot discern what the problem is. I just want the error returned to the client.

For additional background info, I do have the following settings set under <serviceBehavior><behavior>... in the service's web.config:

<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>

...and I'm using the wsHttpBinding and mex bindings.

Lastly, this seems to be a fairly recent change in behavior (i.e., the clients used to see the actual exceptions being thrown by the services). I just cannot figure out what might have chnaged.

Answer 1

If I remember correctly, I think it depends on when the exception occurs: I.e. in your case, the quota exception happens too early in the pipeline, while the incoming message from the client is still being deserialized - and so the server just aborts the connection, because it doesn't consider the incoming message a valid request at all (because it couldn't be deserialized), and so from it's perspective there's nothing to reply to.