WCF distributed development step by step for win (15)

Today, learn the WCF distributed development step-by-step for winning series 15: Error contract (FAULTCONTRACT) and exception handling (Exceptionhandle). This section is an important knowledge of WCF distributed development, and should be understood in both learning and project. Previously, and a number of learning enthusiasts have discussed WCF exception handling knowledge. Here on the system to clean up, a total of reference. At the same time, the "WCF Distributed development step-by-step for Win" series of articles to improve and complement.

The main points of knowledge in this section are: "1". NET exception Handling "2" WCF Exception handling "3" Error Contract "4" WCF Exception Handling Extension "5" Sample code analysis, and finally the "6" Summary section.

First, let's recall. NET in an important concept of exception handling Exceptionhandle. Exception handling in the Java platform also has its own mechanism, this is not a WCF-specific concept, but also to understand the WCF exception handling, we need to first understand its predecessor. NET's exception handling concepts.

"1". NET exception handling:

Managed exceptions in the. NET Framework are implemented by the WIN32 structured exception handling mechanism. The common language runtime provides a model that notifies the program of errors in a uniform way, which provides a great help in designing fault-tolerant software. All. NET framework operations indicate an error by throwing an exception. Traditionally, language error-handling models rely on language detection errors and unique methods of locating error handlers, or on error-handling mechanisms provided by the operating system. Exception handling implemented by the runtime has the following characteristics:

Exceptions are handled without regard to the language that generated the exception or the language that handles the exception.

Exception handling does not require any specific language syntax, but rather allows each language to define its own syntax.

Allows exceptions to be thrown across processes or even across computer boundaries.

Exceptions have several advantages over other error notification methods, such as return codes. There is no longer a situation where there is an error and no one notices it. Invalid values will not continue to propagate in the system. You do not have to check the return code. Exception handling code can be easily added to increase the reliability of the program. Finally, the runtime's exception handling is faster than windows-based C + + error handling.

Because the execution thread routinely traverses managed and unmanaged blocks of code, the runtime can throw or catch exceptions in managed or unmanaged code. Unmanaged code can contain both C + +-style SEH exceptions and COM-based HRESULT.

Exception handling uses try, catch, and finally keywords to try some operations to handle failures, although these operations may fail, but if you are certain that you need to do so and you want to clean up the resources afterwards, you can try to do so. An exception can be generated by the common language runtime (CLR), the. NET Framework, or any Third-party library or application code. Exceptions are created using the Throw keyword. (MSDN)

"2" WCF Exception handling:

Now let's take a look at WCF's exception handling mechanism. We introduced the previous. NET exception handling mechanism. WCF is also part of the. NET Framework, many of which are essentially the same. However, because of its cross service platform's goal request, the WCF does not support the traditional exception processing way. The traditional way. NET throws an unhandled exception immediately terminates the main process, while WCF does not.

"2.1" WCF Error Type:

In the process of developing WCF distributed applications, our clients often encounter three common errors.

(1): Communication error, May and network, channel and other related anomalies, client performance for communication Exception;

(2): Agent and Channel State, the agent has been closed, or channel fault, and so on, this is more common. The General channel idle time is too long, the channel can appear this state error problem. Generally we can judge by the state of the agent. This error can also be caused by security validation failures.

(3): The service invocation error, the exception thrown when the service is invoked, the service internal exception is serialized to the client and captured by the client.

The third is the type of detail we are talking about this section.