Question

I have project in which i am calling soap based service . I am using fault and communication exception as mostly two of these exception occurs in calling of api. but what if any other exception occurs instead of these two exception in soap api ?

    try
    {
      //soap api
    }
    catch(FaultException ex)
    {
    }
    catch(CommunicationException ex)
    {
    }

Later on i read on internet about soap exception class. and i am considering to change my code like :

     try
    {
      //soap api
    }

    catch(SoapException ex)
    {
    }

Now what i need to know is if i use Soap Exception instead of fault and communication exception . would it be good ? all i need is the catch the exception if it occurs in soap api. however i want to know does the soap api also handles the fault and communication exception or i have to explicitly define my code like ?

 try
    {
      //soap api
    }
    catch(FaultException ex)
    {
    }
    catch(CommunicationException ex)
    {
    }
    catch(SoapException ex)
    {
    }
Was it helpful?

Solution

You will never see a SoapException. That's part of the obsolete ASMX technology.

See Specifying and Handling Faults in Contracts and Services.

OTHER TIPS

As stated on MSDN:

The errors encountered by a WCF application belong to one of three groups:

  • Communication Errors
  • Proxy/Channel Errors
  • Application Errors

Communication errors occur when a network is unavailable, a client uses an incorrect address, or the service host is not listening for incoming messages. Errors of this type are returned to the client as CommunicationException or CommunicationException-derived classes.

Proxy/Channel errors are errors that occur within the channel or proxy itself. Errors of this type include: attempting to use a proxy or channel that has been closed, a contract mismatch exists between the client and service, or the client’s credentials are rejected by the service. There are many different types of errors in this category, too many to list here. Errors of this type are returned to the client as-is (no transformation is performed on the exception objects).

Application errors occur during the execution of a service operation. Errors of this kind are sent to the client as FaultException or FaultException<TDetail>.

Error handling in WCF is performed by one or more of the following:

  • Directly handling the exception thrown. This is only done for communication and proxy/channel errors.
  • Using fault contracts
  • Implementing the IErrorHandler interface
  • Handling ServiceHost events

Fault Contracts Fault contracts allow you to define the errors that can occur during service operation in a platform independent way. By default all exceptions thrown from within a service operation will be returned to the client as a FaultException object. The FaultException object will contain very little information. You can control the information sent to the client by defining a fault contract and returning the error as a FaultException. For more information, see Specifying and Handling Faults in Contracts and Services.

IErrorHandler The IErrorHandler interface allows you more control over how your WCF application responds to errors. It gives you full control over the fault message that is returned to the client and allows you to perform custom error processing such as logging. For more information, see IErrorHandler and Extending Control Over Error Handling and Reporting

ServiceHost Events The ServiceHost class hosts services and defines several events that may be needed for handling errors. For example:

1.Faulted

2.UnknownMessageReceived

You can also refer to a similar question, which has many good answers as well: What is the best approach to handle exceptions in WCF service?

If you have the timeline to create a nice set of custom Exceptions extending from ClientSafeException then I would divide those up between client friendly exceptions and non-client friendly exceptions.

catch (ClientSafeException safeException)
{
    response.ServiceResponse= ExceptionHandler.ProcessSafeExceptionResponse(safeException);
     request.Succeeded = false;
}
catch (Exception unsafeException)
{
    response.ServiceResponse= ExceptionHandler.ProcessUnsafeExceptionResponse(unsafeException);
    request.Succeeded = false;
}
LogServiceResponse(request, response.ServiceResponse);

return response;

Sorry to not mention that the static ExceptionHandler class routes safe vs. non-safe client exceptions.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top