. Net 4.0 new feature-upted state exceptions

ArticleDirectory

• Why should I initialize upted state exceptions?
• How does CLR handle writable upted state exception?
• Summary

AsProgramClerk, I think many people should have had experience dealing with exceptions. I believe many people have also written catch (exception e) {// blabla}, which captures and processes all unknown exceptions.CodeRight. Whether it is for a perfunctory customer or to allow the program to continue running to avoid poor user experience, in the eyes of Microsoft, this kind of processing method is not a drop, especially when your program is stored as a plug-in other programs such as Vs and offcie, in this case, for some serious exceptions such as access conflicts, we should end the program rather than continue running. However, in many cases, we do not know which exceptions are serious or which programs can continue to run. before net 4.0, CLR would faithfully send all exceptions, big and small, to programmers. However, this problem will be well solved in the 4.0 s. This is because the CLR will handle some serious exceptions that may cause the process to crash in a unified manner instead of being handed over to our poor programmers. Next I will give a brief introduction to this kind of exception handling.

Why should I initialize upted state exceptions?

Exceptions are large, small, and small. For example, if the string is null, these errors are generally caused by user input, which will not cause the crash of the entire program or related processes in the system; large exceptions such as access conflicts may occur because your program is doing something that may cause the operating system to crash. These exceptions are generally serious, generally, the program should end the current process, and then honestly report to the user that you are stupid and prompt him to restart the program. However. before net 4.0, CLR believed that programmers would not come up with irresponsible Code such as catch (exception e) {return;}. Therefore, it is prioritized as long as it is abnormal, it will all be thrown out. There are not only exceptions in hosting code, but also some. net programmers are not very familiar with COM and Win32 exceptions. CLR believes that programmers will only handle the exceptions they know when capturing exceptions. However, many times, as developers, it is really difficult for us to be human because there are bosses and customers below, think about it. If the boss listens and the customer complains that they just click the button twice, the program will report an error and end. Can he give you a raise? Although we often know that our code will not go wrong, it is difficult for us to make sure that everything is correct. In order to give the boss and the customer an explanation, at this time, many people will choose to capture all the exceptions, then record the exception information, and then the program continues running.

It seems that some of them are perfect, and customers will not complain about the program as frequently as before, so the boss will be happy. But some people are unhappy. Small unknown exceptions will certainly not cause a huge flaw, but it may affect some exceptions that may cause program or even the operating system to crash if the program is not interrupted. At this time, the customer may not complain about you, but he will complain that Microsoft has a bad operating system, blue screen one day to night, or he will complain that Microsoft's office or IE is too bad, he only loaded a plug-in, and the entire outlook reported an error. You're saving trouble, but Microsoft has to get it done, and he still doesn't know what's going on in it.

Of course, the above is a joke, but in any case, from the perspective of program security and stability, catch (exception E) is indeed not a good programming habit. However, since it is impossible to avoid programmers from being lazy, microsoft can only take some remedial measures, which is the role of the new CLR exception handling mechanism.

How does CLR handle writable upted state exception?

Since 4.0, CLR will not take the initiative to throw all exceptions for you, and it is considered dangerous for those, exceptions that may cause a process to crash will be marked as upted stateexception and handled by itself rather than thrown to programmers. Exceptions inherited from systemexception, such as accessviolationexception, will be handled as an upted stateexception. However, it should be noted that only the exception type may be dangerous and the CLR will judge the owner of the thrown exception, if it finds that the access conflict is thrown by the operating system, it will be considered as a State crash exception, but if the exception is thrown by the user code, the CLR will not perform special processing on it, it will still throw it normally as before.

The following is an example to demonstrate how the CLR processes an upted state exception in. Net 4.0.

First, we try to create a serious exception, and then use try and catch to see how CLR handles this code.

  Unsafe     Static     Void  T2 (){
  Try 
{
  Int  *  PD  =     Stackalloc     Int  [  1  ];
Pd [  1911  ]  =     2 ;
Console. writeline (Pd [  1111  ]);
}
  Catch  (Exception E)
{
Console. writeline (E. tostring ());
}
}
 

In this Code, even if the user code captures all common exceptions, the program will still terminate and throw the accessviolationexception information, because accessviolationexception is an upted state exception and is thrown by the system. Therefore, the CLR does not send this exception to the user, but reports an error, interrupts the process, and then exits the program.

Let's look at another piece of code:

  Static VoidT3 (){
Try
{
Throw NewSystem. accessviolationeffectio ();
}
Catch(Exception E)
{
Console. writeline (E. tostring ());
}
}
 

Although the Code throws an accessviolationexception, the CLR does not intercept the exception because it is thrown in the user code, instead, the processing responsibility is still handed over to the user. This exception is not generated by the system. It considers that the user is aware of this exception and is responsible for it. Therefore, after this method is executed, the program will not be interrupted, but will continue to be executed.

In addition, CLR will only hand over this dangerous distributed upted state exceptions to itself for handling. For other exceptions that do not cause serious problems, it will still be responsible for the programmer as before.

How to continue capturing upted state exceptions

So does the CLR package this exception handling mean that our programmers will not have to choose to report to users honestly that our products will not work in the future, and then let the boss speculate on us? Which of the products released before. Net 4.0 are vulnerability products. How can we deal with them?

Although Microsoft no longer believes that programmers are in charge of the program, it is also so powerful. Although the CLR will handle these exceptions by default after. Net 4.0, programmers no longer have to worry about these dangerous exceptions. However, you can continue to use your superiors. Microsoft also provides two methods.

For previous programs, Microsoft provides two options:

1. If you want to compile the old code in. NET Framework 4.0 but do not want to modify the code, you can add a new node in the configuration file of your program:Legacypolicuptedstateexceptionspolicy = trueIt allows your code to continue running as it previously handled exceptions.

2. if you don't want any changes, directly put the previously compiled program in. net Framework 4.0 does not need to be changed. CLR will ensure that all exceptions are still handled in the previous way.

Secondly, for those used. net Framework 4.0 but want to handle these exceptions that cause program state crash, Microsoft also provides the option, they are in. net 4.0 adds a new namespace: system. runtime. exceptionservices, there is a feature class called handleprocesscorruptedstateexceptionsattribute. You only need to add this property to the corresponding method, and CLR will handle all the exceptions to you, just as before. E.g.

Code

  [Handledprocesscorruptedstateexceptions]
  Public     Static     Int  Main (){
  Try  
{
  //  Capture exceptions in any system  
 Callmainprogramloop ();
}
  Catch  (Exception E)
{  //  Here we can catch any exceptions
  //  Here, we will capture any exceptions, including common and system-level exceptions,
  //  And we know that the system may throw some high-level exceptions that cause program crash.  
  System. Console. writeline (E. Message );
  Return     1 ;
}
  Return     0  ;
} 

 

Of course, you must note that this feature can only be applied to methods.

Summary

Exception Handling is often a heart disease for programmers. Although Microsoft thinks it is necessary to indulge programmers in misuse of exception capture and then add this new exception handling mechanism, in their view, the catch (exception e) behavior is still incorrect. They think that exceptions indicate that the current state of the program has encountered a problem, and the programmer should be clear about the consequences of these wrong states, so the programmer should capture specific exceptions and make the correct handling, instead of simply handling all exceptions because of laziness or worry-free.

References:

Handling successful upted state tions by Andrew Pardoe http://msdn.microsoft.com/en-us/magazine/dd419661.aspx