Question on TCPChunkingBinding Exception handling RRS feed

  • Question

  • Hi,

    I been trying to use TcpChunkingBinding implementation that I found on web for one of my use cases - transferring images between 2 apps. Basically, I have a client which sends the image and the receiver is always a WCF endpoint that gets and saves the image. This setup works fine for my happy path scenarios. But I have defined a custom MessageContract object to pass in some additional meta data about the image as well. This messagecontract class has some MessageHeaders (the metadata) and then the Image (Stream) as the MessageBody. 

    Now here is my issue, on the receiver side, I do some validation on the Metadata and might want to abort the transfer without reading the stream itself. But with TcpChunkingBinding, I figured out that the client already has put some chunks on the network and waits for them to be read by the receiver. So even though, I throw an exception from the receiver, it actually never reaches the client - guess it's because of a ManualResetEvent that is waiting for the Stream transfer to complete. 

    What is the recommended way to handle this? I tried to take the callback approach but that didn't work because the Async methods are not implemented for TcpChunkingBinding. Any help/pointers would be highly appreciated!!


    Saturday, October 19, 2013 5:11 PM

All replies

  • From a WCF service perspective, all the normal exceptions inside the WCF service can still be handled in the similar manner as if they are normal .NET exceptions. In fact they are normal .NET exceptions. The major challenge for a service is to propagate the exception information to the user. The reason for this is that the user of the service will most probably be consuming the service in form of document and soap messages and  secondly because the the consumer of the service could be in some other technology and sending him .NET specific exception doesn't make any sense.

    Sending the exception information to the user is never a good idea. So when I say sending the exception information to the user, the user is in fact the application/developers which is trying to consume the service and  not the end user. End user should always meet with user friendly messages and never with the exceptions. The  consuming application developers, on the other hand, need to know the details of the application so that they can understand what is going wrong and what corrective actions should be taken.

    In a service based application scenario when the applications are talking in terms of documents i.e. soap messages the error and exception reporting from the service to the service consumer also happen in the form of soap elements. SOAP faults are the way to propagate the exceptions from the service to the client application.

    Does this mean the service developers will have to create the SOAP's fault manually whenever any exception is met. The answer to that is no. WCF services provide a very nice abstraction over these in form of FaultException and the services can easily propagate the exception information to the client using the FaultException and FaultContract.

    • Proposed as answer by Mernández Wednesday, November 6, 2013 9:38 AM
    • Unproposed as answer by easwarr Wednesday, November 6, 2013 9:40 AM
    Monday, October 28, 2013 8:31 AM