What exceptions may a generated service reference throw?

Question

I have added a web service in Visual Studio 2010 using the "Add Service Reference...". This generates some code in a file called Reference.cs. Now, if I call one of the methods I wan't to know what exceptions the method may throw. Presumably it can throw network related exceptions such as SocketException or IOException?

Regular methods in .NET can be checked on msdn or inside the source code to reveal what exceptions may be thrown, like for example File.Open. Here it's clear what exceptions I should catch and rethrow to show error messages at a later stage.

For those generated methods, how can I know what exceptions they may throw?

Answer 1

Well, there are 'standard' exceptions in this case, and 'custom' exceptions (those defined as FaultContacts by the service developer and present in the service contract reference).

In the first case your concerns, I would suppose, are CommunicationException and TimeoutException; these are documented possible exceptions for ICommunicationObject.BeginOpen and other 'opening' methods of ICommunicationObject (the base of the model). CommunicationObjectFaultedException is documented for 'closing' methods. There is also QuotaExceededException for methods that send messages, such as IRequestChannel.Request. Among the many more that might be, these should be discoverable.

Worth noting, from an MSDN article linked above, is this:

All exceptions thrown by channels must be either a System.TimeoutException, System.ServiceModel.CommunicationException, or a type derived from CommunicationException. (Exceptions such as ObjectDisposedException may also be thrown, but only to indicate that the calling code has misused the channel. If a channel is used correctly, it must only throw the given exceptions.)

Then there are 'Faults', which are exceptions raised on the service-side and (potentially, if enabled) are detailed to the caller, the caller can then handle that or throw the proper client-side exception:

When generating a fault, the custom channel should not send the fault directly, rather, it should throw an exception and let the layer above decide whether to convert that exception to a fault and how to send it.

The channel State offers an event of Faulted to which you can subscribe to to be informed when such a state it reached, and perhaps act. By default (without configuring supression (?)) the faults will be raised as managed exceptions; again, to reiterate:

In WCF clients, SOAP faults that occur during communication that are of interest to client applications are raised as managed exceptions. While there are many exceptions that can occur during the execution of any program, applications using the WCF client programming model can expect to handle exceptions of the [...] two types as a result of communication.

And this refers again to the CommunicationException and TimeoutException mentioned above.

Lastly, for now at least, is the unexpected:

FaultException exceptions are thrown when a listener receives a fault that is not expected or specified in the operation contract; usually this occurs when the application is being debugged and the service has the System.ServiceModel.Description.ServiceDebugBehavior.IncludeExceptionDetailInFaults property set to true.