A Preliminary Study on WCF-12: Exception Handling on the WCF client, a preliminary study on wcf-12 Exception Handling

A Preliminary Study on WCF-12: Exception Handling on the WCF client, a preliminary study on wcf-12 Exception Handling

Preface:

• When we open the basic client channel of WCF (whether it is automatically opened through explicit or call operations), use the client or channel object to call operations, or close the basic client channel, exceptions occur in client applications. However, we know that WCF is a network-based communication service, and error exceptions must be transmitted Based on messages. In WCF, A FaultException class is provided for error message processing. Next, let's take a look at how to use it to handle exceptions on the client.

WCFException type:

• Unexpected exceptions: Unexpected exceptions include catastrophic faults (such as OutOfMemoryException) and programming errors (such as ArgumentNullException or InvalidOperationException ). There are usually no effective methods to handle unexpected errors, so these exceptions should not be caught when calling the communication method of the WCF client.
• Expected exceptions: Expected exceptions include TimeoutException, CommunicationException, and any Derived classes of CommunicationException. These exceptions indicate a problem in the communication process. You can safely handle the problem by suspending the WCF client and reporting a communication fault. Because external factors may cause these errors in any application, the correct application must capture these exceptions and restore them in case of exceptions.

WCFClient Exception Handling example:

• Shows the project structure:

　　

• Engineering Structure Description:

The ICalculator. cs code is as follows:

Using System. serviceModel; using System. collections. generic; using System. runtime. serialization; namespace Service {[ServiceContract] public interface ICalculator {[OperationContract] int Add (int value1, int value2); [OperationContract] int Divide (int value1, int value2 );}}View Code

The Calculator. cs code is as follows:

Using System; using System. collections. generic; using System. linq; using System. text; using System. serviceModel; namespace Service {public class Calculator: ICalculator {public int Add (int value1, int value2) {return value1 + value2;} public int Divide (int value1, int value2) {try {return value1/value2;} catch (DivideByZeroException) {throw new FaultException ("Division cannot be 0 ");}}}}View Code

2. Host: console application. Used to carry the Service. After adding a reference to the Service assembly, the following code can carry the Service.

The Code of Program. cs is as follows:

Using System; using System. collections. generic; using System. linq; using System. text; using Service; using System. serviceModel; namespace Host {class Program {static void Main (string [] args) {using (ServiceHost host = new ServiceHost (typeof (Calculator) {host. opened + = delegate {Console. writeLine ("the service has been started. Press any key to terminate! ") ;}; Host. Open (); Console. Read ();}}}}View Code

The code for App. config is as follows:

<? Xml version = "1.0"?> <Configuration> <system. serviceModel> <services> <service name = "Service. calculator "behaviorConfiguration =" mexBehavior "> 3. Client: console application. After the Host bearer service is started, the client program adds a reference to the service address http: // localhost: 1234/Calculator/and sets the namespace to CalculatorServiceRef,

Next we can call the service. The Client's Program. cs code is as follows:

　　

First, we comment out the code 2 and 3, and only verify the result thrown by the Service exception. We set Divide's Divide to 0. At this time, we should capture the exception information thrown by the server. The running result is as follows:

　　

Then, we comment 1 and 3 to verify that only the communication timeout exception is thrown. We set the operation time after the channel connection to a very small value, so the server's operation is certainly too late to process, it will throw a super

Exception information. The running result is as follows:

　　

Finally, we will comment 1 and 2 to verify only the communication error exception information. After the client executes Add (), we will terminate the service, that is, when the service terminates the connection, an exception message indicating a communication error is thrown. The running result is as follows:

　　

Summary:

• The example shows that the client successfully captured TimeoutException, CommunicationException, and custom exception information.
• If an expected exception occurs, the client may continue to use it, or may not continue to use it. To determine whether the client can still be used, check whether the State attribute is CommunicationState. Opened.

If the property is still open, the client can still use it. Otherwise, stop the client and release all references to it. The Code is as follows:

if (proxy.State == CommunicationState.Opened){    Console.WriteLine("CommunicationState is Opened"); }