From theory to practice (10): Exception Handling

From theory to practice (10): Exception Handling

Purpose

By reading this article, you can understand the following knowledge:

1) which exception handling methods exist in WCF?
2) What are the application scenarios for exception handling?
3) what are common exception types in WCF?
4)CodeDo not lie. Use examples to demonstrate the effect and deepen your impression.

This article is suitable for readers

This article is suitable for beginners of WCF, but requires some understanding of WCF and simple services/clients.

Which of the following exception handling methods exist in WCF?

WCF defines several exception handling models, which are as follows:

1) Default Mode
2) Detailed Information Mode
3) custom exception message mode

What are the application scenarios for exception handling?

1) Default Mode

By default, if an exception occurs on the server side, the client will obtain a default exception, but this exception instance does not contain detailed exception information. It only tells the client that the server cannot work normally. In server and client ModeProgramIn some cases, the service cannot fully trust the client. For example, between a browser and a Web server, in order to prevent illegal clients from obtaining detailed information from the exception message, this makes it possible for people who are willing to take advantage of the test. Therefore, service initiation is usually vague for abnormal responses. WCF also adopts this approach. By default, the exception it returns to the client only informs me of the error, but does not tell anyone where it is wrong. This is usually applied to production environments with unknown client sources to protect service programs. 

2) Detailed Information Mode

If you want to make the message more friendly, you can use includeexceptiondetailinfaults = true to set the returned exception information, so that you can tell the client about the service error and identify the error. In the program development stage or in some applications, the client is trusted. In order to give the client a more detailed understanding of what is wrong with the server, WCF also supports sending detailed error messages to clients, which is more conducive to application debugging. There are two methods to return detailed exceptions: the first one is to set in the server configuration file: <servicedebug includeexceptiondetailinfaults = "false"/>, the second method is to specify in the Code: [servicebehavior (includeexceptiondetailinfaults = true)]

3) custom exception message mode

In WCF, more detailed exception messages are also supported. The custom exception message faultmessage is used to convey more content. WCF uses common soap fault to handle exceptions, and provides two types of description and operation exception: faultexception and faultexception <faultmessage>.

Common exception types in WCF?

WCF includes three common types of exceptions:

1) communication exception. This is usually due to link reasons, such as service failure or network congestion. This type of exception is communicationexception or its derived class.
2) Status exceptions. These exceptions are usually related to the instance mode mentioned above. When a server object that has been destroyed is accessed, this type of exceptions is thrown. They are usually objectdisposedexception.
3) a service exception is triggered by the server based on the specific business logic, usually faultexception.It is worth noting that when a service exception is thrown, the processing methods of different instance modes are different:

Persession: In this mode, an exception is thrown, the service instance is destroyed, the client throws a faultexception, and the client proxy object cannot be used.

Percall: In this mode, an exception is thrown and the service instance is also destroyed. The client proxy object cannot be used.

Single: In this mode, an exception is thrown and the service instance runs as usual. The client proxy cannot be used.

The code is not a lie. Use examples to demonstrate the effect and deepen your impression.

The examples implemented in this article are very simple. The purpose is to verify the different performance of various exception handling methods.

1) Default Mode

In this example, an exception is thrown.

Public   String Getwelcomeinfo ([paraatt (cansetnull = False )] String Name)

{

Parameterinfo para = Methodinfo. getcurrentmethod (). getparameters ()[ 0 ];

Paraatt = Paraatt. getcustomattriatt (para, Typeof (Paraatt )) As Paraatt;

If ( ! Att. cansetnull && Name =   Null )

{

Throw NewException ("The parameter cannot be set to null.");

}  

Return   " Hello, "   + Name;

}  

At this time, we can run the client and find the following running results:

The results show that, by default, although the client runs out of exceptions, these exception messages are not presented to the client.

2) Detailed Information Mode

Restart <servicedebug includeexceptiondetailinfaults = "true"/> in the server configuration file. In this case, the client not only receives consistent tracing stack information, but also displays exception messages to the client.

3) custom exception message mode

This mode is the most difficult to handle exceptions. Because it is more flexible, we first define a data contract predictionmsg to indicate error messages, as shown below:

Using System;

Using System. Collections. Generic;

Using System. LINQ;

Using System. text;

Using System. runtime. serialization;

 

Namespace Jillzhang. WCF. excontracts

{

[Datacontract]

Public   Class Predictionmsg

{

/**/ /// <Summary> 

///Exception message text

/// </Summary> 

[Datamember]

Public   String Message {Get;Set;}  

 

/**/ /// <Summary> 

///Exception Code

/// </Summary> 

[Datamember]

Public   String Errorcode {Get;Set;}  

}  

}  

When defining an operation, we can specify the type of the returned exception message as follows:

[Operationcontract]

[Faultcontract ( Typeof (Exceptionmsg)]

Int Devide ( Int X, Int Y );

Run the instance program and obtain the following results:

We can use tcptrace to track abnormal messages.ArticleFrom theory to practice 2: a decisive battle Description. This article describes the exception method used to track basichttpbinding. For this reason, we need to prepare a tool, trace utility, which is a tool in Microsoft soap Toolkit version 3. It can be used to clearly see soapmessage, the method is as follows: Open trace utility, select the menu item file-formated trace, and fill in the following dialog box with the port to be listened on and the port of the service, as shown in:

Click OK

Change

Start to track the soapmessage in the trace utility, as shown below:

- < S: Envelope Xmlns: S = "Http://schemas.xmlsoap.org/soap/envelope" >  

- < S: Body >  

- < S: Fault >  

< Faultcode > S: Client </ Faultcode >  

< Faultstring XML: Lang = "ZH-CN" > The creator of this fault did not specify a reason. </ Faultstring >  

- < Detail >  

- < Predictionmsg Xmlns = "Http://schemas.datacontract.org/2004/07/Jillzhang.Wcf.ExContracts" Xmlns: I = "Http://www.w3.org/2001/XMLSchema-instance" >  

< Errorcode > 001 </ Errorcode >  

< Message > The divisor cannot be 0. </ Message >  

</ Predictionmsg >  

</ Detail >  

</ S: Fault >  

</ S: Body >  

</ S: Envelope >  

In addition, many people do not know how to debug and track the WCF application. In particular, to track the service from the customer segment, follow these steps:

References

1. Http://www.rainsts.net/article.asp? Id = 430

Example project:

/Files/jillzhang/jillzhang.wcf.exceptionhandler.rar