Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "what is the new mechanism of exception handling in .NET 4". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

After .NET 4.0, CLR will distinguish some exceptions (all SEH exceptions) and identify them as destructive exceptions (Corrupted State Exception). For these exceptions, CLR's catch block does not catch them, even if you use code similar to the following:

Try {TestMethod ();} catch (Exception e) {Console.WriteLine ("Catching exception: {0}", e);}

There is no way to catch these anomalies. The reason for this design has been mentioned in MSDN's article Handling Corrupted State Exceptions. That is, there are plug-in-supporting programs, such as Visual Studio or SQL Server, that support calling plug-ins written in managed code, but they have a lot of their own code written by unmanaged C++. Because plug-ins often call unmanaged API, most of the time, the code of these plug-ins simply doesn't know how to handle SEH exceptions thrown by unmanaged API. Before 4. 0, because SEH exceptions were converted to the same exceptions as normal .NET exceptions, programmers could catch all exceptions simply by using the catch (Exception e) pattern. The problem with this is that since SEH exceptions are not usually thrown by managed code, managed code has no idea why the SHE exception was thrown, and simple catch (Exception e) handling puts the whole program in a very unstable state, causing previously ignored problems to arise in a more serious way later-such as saving corrupted data. In this way, it may seem simple to use catch (Exception e) to handle all exceptions, but it actually takes more effort for programmers or users to analyze when the problem is delayed.

So after 4.0, most SHE (and I suspect all) exceptions are identified as destructive, and in .NET, CLR doesn't catch them by default, but leaves them to the operating system to handle-that is, close the program and open an error dialog to notify the user. To ensure compatibility, programs compiled before 4.0, such as those compiled in 2.0,3.0, and 3.5, still follow the old strategy-that is, .NET catches both .NET and SHE exceptions. Programs compiled under 4.0 will use the new strategy, which is the problem my friend encountered at the beginning of the article. You can experience this new change by compiling the following program under .NET 4.0:

Program.cs

Using System; using System.Runtime.InteropServices; namespace ConsoleApplication1 {class Program {[DllImport ("Ref.dll")] private extern static void TestMethod (); static void Main (string [] args) {try {TestMethod () } catch (Exception e) {Console.WriteLine ("Catching exception: {0}", e);}

Ref.cpp:

# include "stdafx.h" extern "C" _ declspec (dllexport) void TestMethod () {int * p = NULL; / / causes .NET to throw an AccessViolation exception * p = 10;}

In the above code, Program.cs uses P/Invoke technology to call TestMethod in the Ref.dll file, but TestMethod attempts to assign a null pointer, resulting in an AccessViolation exception. If you compile program.cs under 2.0 and execute it, the AccessViolation exception will be caught by catch (Exception e), while if you compile and execute it under 4.0, you will find that catch (Exception e) cannot catch this exception.

However, not everyone wants this new exception mechanism. If your program is compiled and running under 4.0, and you want to catch SHE exceptions in .NET programs, there are two options to try:

1. In the .config file of the managed program, enable the property legacyCorruptedStateExceptionsPolicy, that is, the simplified .config file looks like the following file:

App.config:

This setting tells CLR 4. 0 that the entire .NET program should use the old exception catching mechanism.

two。 Add a HandleProcessCorruptedStateExceptions attribute to the function that needs to catch destructive exceptions, which controls only one function and has no effect on other functions of the managed program, such as:

[HandleProcessCorruptedStateExceptions] static void Main (string [] args) {try {TestMethod ();} catch (Exception e) {Console.WriteLine ("Catching exception: {0}", e);}} "what is the new mechanism for exception handling in .NET 4". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.