Describes the new features of exception handling in. Net 4.0.

 

 

As a programmer, I think many people should have experienced dealing with exceptions. I believe many people have also written catch (catch tione) {// blabla}, a code that captures and processes all unknown exceptions. 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 net4.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 net4.0, CLR was confident that programmers would not come up with irresponsible Code such as catch (catch tione) {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 (catch) 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. Here they add a new exception handling mechanism in clr4. Since 4.0, CLR will not throw you all exceptions, for exceptions that it deems dangerous and may cause a process crash, it is marked as uptedstateexception and handled by itself instead of being thrown to the programmer, exceptions inherited from systemexception, such as accessviolationexception, will be handled as corruptedstateexception. 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.

 

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 net4.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. net4.0, programmers do not 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 put the old code in. if netframework4.0 is compiled but you do not want to modify the code, you can add a new node in your program configuration file: legacycorruptedstate -- exceptionspolicy = true, it allows your code to continue running as it previously handled exceptions.

 

2. If you don't want any changes, run the previously compiled program in. netframework4.0 without any changes. CLR will ensure that all exceptions are still handled in the previous way.

 

Secondly, for those used. netframework4.0 but wants to handle these exceptions that cause program state crash, Microsoft also provides the option, they are in. net4.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 highlighting produced byactiprocodehighlighter (freeware)

Http://www.CodeHighlighter.com/

--> View sourceprint? 01 // This program runs aspartofanautomated test system so you need

// To prevent the normal unhandledexceptionbehavior (watsondialog ).

// Instead, print out any exceptions and exitwithanerrorcode.

[Handledprocesscorruptedstateexceptions]

Public static int main ()

{

Try

{// Catch any exceptions leaking out of the program

Callmainprogramloop ();

}

Catch (exception e) // We cocould be catching anything here

{// The exception we caught cocould have been a program error

// Or something much more serious. Regardless, we know that

// Something is not right. Well just output the exception

// And exit with an error. We wont try to do any work when

// The program or process is in an unknown state!

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 (except tione) 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.