ASP技巧：了解NET 4.0新特性

日期：09-08 来源：中国设计秀作者：cnwebshow.com

首先，我们想办法制造一个这种严重的异常，然后使用try,catch来看CLR是如何处理这段代码的。

view sourcePRint?01 unsafe static void T2()

02 {

03    try

04    {

05         int* pd = stackalloc int[1];

06         pd[1911] = 2;

07         Console.WriteLine(pd[1111]);

08    }

09    catch (Exception e)

10    {

11         Console.WriteLine(e.ToString());

12     }

13 }

在这段代码中，即使用户代码捕获所有通用异常，程序仍然会终止并抛出AccessViolationException异常信息，这是因为AccessViolationException是Corrupted　State异常，并且它是由系统抛出。所以这里CLR不会把这个异常交给用户处理，而是主动报告错误，中断进程，然后退出程序。

我们再看另外一段代码：

view sourceprint?01 static void T3()

02 {

03     try

04     {

05         throw new System.AccessViolationException();

06     }

07     catch (Exception e)

08     {

09         Console.WriteLine(e.ToString());

10     }

11 }

这里虽然代码抛出的仍然是一个AccessViolationException异常，但由于它是在用户代码中抛出，因此这里CLR并不会将其拦截自己处理，而是仍然把处理的责任交给了用户。因为这里这个异常并非系统产生的，它认为用户清楚这个异常并能对其负责。所以这个方法执行之后程序不会中断，而是继续执行。

另外CLR也只会将这种危险的Corrupted State Exceptions交给它自己处理，对于其他的不会引起严重问题的异常它仍然像以往一样抛给程序员自己负责。

如何继续捕获Corrupted State Exceptions
那么CLR包了这块的异常处理是不是意味着以后我们程序员就没得选只能老老实实向用户报告我们的产品不行，然后让老板炒我们鱿鱼了呢？那些.NET 4.0以前发布的，处处是漏洞的产品我们怎么处理？

虽然微软不再那么相信程序员是负责人的人，但它也做那么绝。虽然默认.NET 4.0以后CLR会处理这些异常，程序员也不用再操心这些危险的异常了。但你仍然可以继续你以往敷衍上司的做法。并且微软还提供了两种方式。

首先对于以往的程序，微软提供了两种选择：

1. 如果你想把以往旧的代码在.NET Framework 4.0下编译但又不想改代码的话，你可以在你的程序的配置文件中添加一个新的节点：legacyCorruptedStateExceptionsPolicy=true，它使得你的代码仍能按照以前处理异常的方式来继续运行。

2. 如果你不想有任何改变，直接把以前已经编译好的程序在.NET Framework 4.0下运行则不需要任何改变，CLR会保证所有的异常仍然按照以往的方式处理。

其次，对于那些使用了.NET Framework 4.0 但又想自己处理这些导致程序状态崩溃的异常，微软同样提供了选择，他们在.NET 4.0中增加了一个新的命名空间：System.Runtime.ExceptionServices，这里面有个特性类叫做HandleProcessCorruptedStateExceptionsAttribute，你只需要在相应方法上添加这个属性，CLR就会把所有的异常处理交给你做，就像以前一样。e.g.

view sourceprint?01 // This program runs as part of an automated test system so you need

02 // to prevent the normal Unhandled Exception behavior (Watson dialog).

03 // Instead, print out any exceptions and exit with an error code.

04 [HandledProcessCorruptedStateExceptions]

05 public static int Main()

06 {

07     try

08     {

09         // Catch any exceptions leaking out of the program

10         CallMainProgramLoop();

11     }

12     catch (Exception e) // We could be catching anything here

13     {

14         // The exception we caught could have been a program error

15         // or something much more serious. Regardless, we know that

16         // something is not right. We'll just output the exception

17         // and exit with an error. We won't try to do any work when

18         // the program or process is in an unknown state!

19         System.Console.WriteLine(e.Message);

20         return 1;

21     }

22     return 0;

23   }

view sourceprint?1 当然要注意的是这个特性只能应用在方法上。

总结
异常处理常常是程序员心中的一块心病，尽管微软认为自己得为纵容程序员滥用异常捕获负责然后添加了这个新的异常处理机制，不过在他们看来，那种catch(Exception e)的行为仍然是不对的。他们认为异常的出现表明当前程序的状态出现了问题，而程序员应当清楚这些错误的状态所造成的后果，所以程序员应当捕获具体的异常并作出正确的处理，而不是因为偷懒或者省事去简单处理所有异常。

参考资料：

Handling Corrupted State Exceptions        作者：Andrew Pardoe

原文地址：http://msdn.microsoft.com/en-us/magazine/dd419661.aspx

作者：Sean Zhu
出处：http://jujusharp.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。