WCF Technical Analysis 21: WCF basic exception handling mode [previous]

Because WCF uses the. NET Managed language (C # and net) as its primary programming language, it is doomed to be a WCF-based programming approach that cannot be complicated. At the same time, one of the purposes of WCF design is to provide communication implementations based on non-business logic and to provide programmers with an Easy-to-use application programming interface (API). The simplicity of the WCF programming model is also reflected in the exception handling, the main purpose of this article is to make a simple introduction to WCF based on exception handling programming mode.

First, when the exception is thrown from the service side

For a typical WCF service invocation, I personally tend to have two types of potentially thrown exception fees: applying exceptions (Application Exception) and infrastructure (infrastructure Exception). The former is the application level, which mainly embodies the exception that is thrown by the business logic that performs a service operation, while the latter is business-independent and is thrown through the infrastructure of WCF itself, mainly in the serialization of objects, message processing, message transmission and distribution of messages, and so on. Here we pay more attention to and apply the exception.

First, let's look at what happens to the client if an exception is thrown during a service operation on a service side without doing any exception handling related operations. We demonstrate this scenario in the form of an instance. In terms of simplicity and ease of understanding, we routinely follow examples of computational services.

We routinely use a typical four-tier architecture (Contract, Service, hosting, and client), with the specific hierarchy in the VS solution division as shown in Figure 1:

Figure 1 Exception throw instance solution structure

The following code fragment represents the definition of a service contract (ICalculator) and a service type (CalculatorService). In order to be concise, in the service contract interface, we define only one method that is used to trigger a budget for two integers divide. Service contracts and service type types are defined separately in project contracts and services.

   1:using System.ServiceModel;
   2:namespace Artech.WcfServices.Contracts
   3: {
   4:     [ServiceContract (Namespace = "http://www.artech.com/")]
   5: Public     interface ICalculator
   6:     {
   7:         [OperationContract]
   8:         int Divide (int x, int y);
   9:     }
  10:}
   1:using Artech.WcfServices.Contracts;
   2:namespace Artech.WcfServices.Services
   3: {
   4: Public     class Calculatorservice:icalculator
   5:     {
   6: Public         int Divide (int x, int y)
   7:         {
   8: Return             x/y;
   9:         }
  :     }
  11:}

The next step is to host the code and related configuration of the WCF service (CALCULATORSERVICE) defined above through the console application (hosting project).

1:using System;
2:using System.ServiceModel;
3:using Artech.WcfServices.Services;
4:namespace Artech.WcfServices.Hosting
5: {
6:public class Program
7: {
8:static void Main (string[] args)
9: {
10:using (ServiceHost host = new ServiceHost (typeof (CalculatorService)))
11: {
12:
13:host. Open ();
14:console.read ();
15:}
16:}
17:}
18:}
1: <?xml version= "1.0" encoding= "Utf-8"?>
2: <configuration>
3: <system.serviceModel>
4: <services>
5: <service name= "Artech.WcfServices.Services.CalculatorService" >
6: <endpoint address= "Http://127.0.0.1:3721/calculatorservice" binding= "Wshttpbinding" contract= "Artech" . WcfServices.Contracts.ICalculator "/>
7: </service>
8: </services>
9: </system.serviceModel>
: </configuration>