. Processing of exceptions not caught under net

With. NET technology development,. NET technology has been gradually applied to many large application software projects. These projects are growing in size, and many projects refer to many third party. NET components in addition to their own code. At the same time, many projects have been applied to many key departments, the stability of software systems is more and more important. Because the. Net Framework provides a very powerful exception handling mechanism, it provides a good solution for system problems that are difficult to control in some unmanaged code, such as pointer crossings, memory leaks, and so on. Compared to systems built by unmanaged code,. NET builds more stable systems. But that's not to say. NET built system is completely unassailable, many due to the code is not rigorous or system problems caused by the fault will be caused. NET application produces an unhandled exception, which causes the application to terminate abnormally. This article will be for three of the most common. NET application and describes the unhandled exception handling.

Before we begin this article, let's take a look. NET under what circumstances it will produce an unhandled exception. An exception that is not caught by definition is the exception that the structured exception handling failed to catch. In layman's terms, unexpected exceptions occur in a try catch block. So are we going to add a try Catch block to the main function to catch all the catch exceptions? The answer is in the negative. There are two situations in which you cannot capture this method:

1. GC-generated exceptions, which are usually caused by an unhandled exception thrown in a finalize function. Of course, this is not absolute, some system problems such as memory exhaustion can sometimes cause GC anomalies.

2. An unhandled exception caused by a thread that the main thread is thinking of. These exceptions can often be captured by a try catch in the main function of the thread, but if the system uses external components, or even some system components from the. Net framework, the exception that is thrown by the threads of these components cannot be captured by the calling code through a try catch.

From the top two point of view, even if our code in each place with a try Catch, it is not completely eliminate the occurrence of not catching exceptions.

In view of this, in order to improve the robustness and maintainability of the system, we need to use a method to intercept these catch exceptions and do the proper processing.

The designers of. Net have taken these issues into account and provided us with an event called Unhandledexceptioneventhandler, through which we can intercept and process the unhandled exception.

The event argument for this event, UnhandledExceptionEventArgs E, has two properties, one is Exceptionobject, and this property is returned as an object instance that intercepts the exception. Another attribute is isterminating, which tells us if this exception will cause the application to terminate. What needs to be explained here is that for. Net1.1 and. Net2.0 and above, the situation is not the same. Net1.1 the application is terminated only if there are no exceptions caught in the main thread, and. Net2.0 and above are always terminating the application. If you do not terminate the application, but have the CLR digest the current exception, the system's running state is likely to be uncontrollable, and a larger failure may occur at the end, so. After Net2.0, the current application is terminated for all not caught exceptions. It seems to me that the application of the net2.0 above seems to have made no sense for us to intercept the anomaly. By intercepting the exception as not caught, we can record where the program is producing this not-caught exception so that the program's developers improve the program. We can also do some other protection work for the system before exiting the current application, such as backing up data, warning prompts, and so on.

Let's take a look at three common types. NET application, respectively, to intercept the not-caught exception.