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

This article will explain in detail what are the new features of exception handling in .NET 4.0. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

As a programmer, I think many people have had the experience of dealing with exceptions. And I believe that many people have also written catch (Exception e) {/ / blabla} code that catches and disposes of all unknown exceptions. Whether it is to perfunctory customers or to keep the program running to avoid a bad user experience, this approach is wrong in Microsoft's eyes, especially if your program is stored as a plug-in in another program such as VS,Offcie, in which case we should let the program end rather than continue to run for some serious exceptions such as access conflicts. In many cases, however, it is not clear which exceptions are serious and which can keep the program running, because before .NET 4.0, CLR faithfully threw all the exceptions, large and small, to programmers. However, this problem will be well solved after 4.0. Because the handling of some serious exceptions that will cause the process to crash will be handled by CLR instead of being handed over to our poor programmers. Below, I will make some brief introduction to this abnormal handling.

Why do you need Corrupted State Exceptions

Exceptions can be large or small, such as empty strings. These are generally user input problems, which will not cause crashes in the whole program or related processes in the system. Big ones, such as access conflict exceptions, may be that your program is doing something that may cause the operating system to crash, which is generally more serious. In general, if such an exception occurs, what the program should usually do is to end the current process. 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;}, so it threw all exceptions regardless of priority, including not only managed code exceptions, but also COM and WIN32 exceptions that were difficult for .NET programmers to understand. CLR believes that programmers will only handle what they know when catching exceptions, but very often, as developers, because there are bosses above and customers below, it is really difficult for us to be human. If the boss often listens to customers complaining that they just click a button and the program is wrong and ends, can he still give you a raise? Although most of the time we know that there will be no problems with our code, it is difficult for us to ensure that there is a good time and everything. In order to give an account to the boss and customers, many people will choose to catch all the exceptions, then record the exception information, and then the program will continue to run.

It seems that some of them are very *. Customers will not complain about the program down as often as before, and the boss will be happy. But some people are unhappy. Of course, a small unknown exception will not cause a big mess, but it may affect a lot of exceptions that may cause the 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 and blue screen all the time, or he will complain that Microsoft's Office or IE is too bad, he just loads a plug-in, and the whole Outlook crashes by mistake. It's easy for you, but Microsoft has to be blamed, and he doesn't know what's going on in it.

Of course, the above is a joke, but anyway, from the point of view of program security and stability, catch (Exception e) is not a good programming habit, but it is done. Since programmers can not avoid being lazy, Microsoft can only take some remedial measures. Here they have added a new exception handling mechanism in CLR 4. Since 4. 0, CLR will not take the initiative to throw all exceptions for you. For those exceptions that it considers dangerous and may cause the process to crash, it will be marked as Corrupted State Exception and disposed of by itself rather than thrown to the programmer. Exceptions such as AccessViolationException, which inherits from SystemException, will be treated as Corrupted State Exception. However, it should be noted that it is not enough for the exception type to be a potentially dangerous exception. CLR will also determine the owner of the exception. If it finds that the access conflict is thrown by the operating system, it will consider it as a state crash exception. But if the exception is thrown by user code, CLR will not handle it specially, it will still throw it normally as before.

How to continue to capture Corrupted State Exceptions

So does CLR's exception handling mean that we programmers will have no choice but to honestly report to our users that our product doesn't work, and then let the boss fire us? What do we do with products that were released before .NET 4.0 and are full of vulnerabilities?

Although Microsoft no longer believes so much that programmers are in charge, it also does so. Although the default. NET 4. 0 CLR will handle these exceptions, programmers no longer have to worry about these dangerous exceptions. But you can still continue what you used to do to your boss. And Microsoft offers two ways.

First of all, for previous programs, Microsoft offers two options:

1. If you want to compile the old code under .NET Framework 4.0but do not want to change the code, you can add a new node to your program's configuration file: legacyCorruptedState ExceptionsPolicy=true, which allows your code to continue to run the way it used to handle exceptions.

two。 If you don't want to make any changes, there is no need to run previously compiled programs under .NET Framework 4.0. CLR will ensure that all exceptions are handled the way they used to be.

Second, for those who use .NET Framework 4.0but want to handle the exceptions that cause the program state to crash, Microsoft also provides a choice. They have added a new namespace in .NET 4.0. there is a feature class called HandleProcessCorruptedStateExceptionsAttribute, and you just need to add this attribute to the corresponding method, and CLR will leave all the exception handling to you, just like before. E.g.

View sourceprint?01 / / This program runs as part of an automated test system so you need / / to prevent the normal Unhandled Exception behavior (Watson dialog). / / Instead, print out any exceptions and exit with an error code. [HandledProcessCorruptedStateExceptions] public static int Main () {try {/ / Catch any exceptions leaking out of the program CallMainProgramLoop ();} catch (Exception) / / We could be catching anything here {/ / The exception we caught could have been a program error / / or something much more serious. Regardless, we know that / / something is not right. We'll just output the exception / / and exit with an error. We won't 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, it is important to note that this feature can only be applied to methods.

This is the end of this article on "what are the new features of exception handling in .NET 4.0?". I hope the above content can be of some help to you, so that you can learn more knowledge. please share it for more people to see.

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.