凡客诚品网站建设策划书,网站导航字体,沧州网页制作,创建网站和主页作为程序员#xff0c;我想很多人应该都有过跟异常打交道的经历。而且相信也有很多人也都写过catch(Exception e){//blabla}这种把所有未知异常一股脑儿捕获并处理掉的代码吧。不管是为敷衍客户也好#xff0c;让程序继续运行以避免糟糕的用户体验也罢#xff0c;在微软眼中… 作为程序员我想很多人应该都有过跟异常打交道的经历。而且相信也有很多人也都写过catch(Exception e){//blabla}这种把所有未知异常一股脑儿捕获并处理掉的代码吧。不管是为敷衍客户也好让程序继续运行以避免糟糕的用户体验也罢在微软眼中这种处理方式都是不对的特别是当你的程序是作为一个插件寄存在别的程序如VS,Offcie中时这种情况下对有些严重的异常如访问冲突我们更应当是让程序结束而不是继续运行。 然而很多时候我们并不清楚哪些异常是严重的哪些是可以让程序继续运行的因为在.NET 4.0以前CLR会很忠实的把所有大大小小的异常一股脑儿的都抛给程序员处理。不过这个问题在4.0以后会得到很好的解决了。因为对有些严重的会引起进程崩溃的异常的处理以后会由CLR来统一处理而不再交给我们可怜的程序员了。下面我将对这种异样处理做一些简单的介绍。 为什么需要Corrupted State Exceptions 异常有大有小小的如字符串为空这些一般是用户输入问题它不会引起整个程序或者系统中相关进程出现崩溃的情况大的如访问冲突异常这可能是你的程序在做一些可能会引起操作系统崩溃的事情这种异常一般都比较严重一般如果出现这种异常通常程序应该做的是结束当前进程然后老老实实向用户报告你犯傻了并提示他重启程序。不过在.NET 4.0以前CLR是很相信程序员不会搞出一些诸如catch(Exception e){return;}这种不负责任的代码的因此它不分轻重缓急只要是异常它统统都会抛出来这里面不仅仅有托管代码的异常也有一些.NET程序员不太好看懂的COM和WIN32异常。CLR相信程序员在捕获异常的时候会只处理他们清楚的异常但很多时候作为开发人员由于上面有老板下面有客户我们真的很难做人想想如果老板动不动就听又客户抱怨他们只不过点了两下按钮程序就报错然后结束了他还能给你加薪么虽然很多时候我们清楚我们的代码不会出问题但我们很难保证天时地利人和样样俱全为了给老板和客户一个交代这时候很多人都会选择去捕获所有的异常然后记录下异常信息然后程序继续彪悍的跑下去。 看似一些都很完美客户不会再像以前那么频繁的抱怨程序down掉老板也就高兴了。但有人不高兴。小的未知异常当然不会捅大的篓子但对有些可能导致程序甚至操作系统崩溃的异常如果不中断程序的话可能影响的就是一大片了。这个时候客户可能不会抱怨你但他会抱怨微软出了个烂操作系统一天到晚蓝屏或者他会抱怨微软的Office或者IE太烂他只不过加载了一个插件结果整个Outlook就报错崩掉了。你是省事了但微软得来被黑锅而且他还不知道这个黑锅里面到底是咋回事。 当然上面是玩笑不过不管怎样从程序安全和稳定的角度来看catch(Exception e)确实不是一个好的编程习惯然而木已成舟既然无法避免程序员偷懒微软只能采取一些补救措施了这里他们在CLR 4中添加了新的异常处理机制自4.0以后CLR不会主动给你抛出所有异常了对于那些它认为是危险的可能导致进程崩溃的异常它会标记为Corrupted State Exception并自己处理掉而不是抛给程序员来做如AccessViolationException这种继承自SystemException的异常就会被当做Corrupted State Exception来处理。不过这里要注意的是仅仅异常类型是可能会危险级别的异常还不够CLR还会判断抛出异常的所有者如果它发现是由操作系统抛出的访问冲突则会认为这是状态崩溃异常但如果异常是由用户代码抛出则CLR不会对其做特殊处理它仍然会像以前一样将其正常抛出。 如何继续捕获Corrupted State Exceptions 那么CLR包了这块的异常处理是不是意味着以后我们程序员就没得选只能老老实实向用户报告我们的产品不行然后让老板炒我们鱿鱼了呢那些.NET 4.0以前发布的处处是漏洞的产品我们怎么处理 虽然微软不再那么相信程序员是负责人的人但它也做那么绝。虽然默认.NET 4.0以后CLR会处理这些异常程序员也不用再操心这些危险的异常了。但你仍然可以继续你以往敷衍上司的做法。并且微软还提供了两种方式。 首先对于以往的程序微软提供了两种选择 1. 如果你想把以往旧的代码在.NET Framework 4.0下编译但又不想改代码的话你可以在你的程序的配置文件中添加一个新的节点legacyCorruptedStateExceptionsPolicytrue它使得你的代码仍能按照以前处理异常的方式来继续运行。 2. 如果你不想有任何改变直接把以前已经编译好的程序在.NET Framework 4.0下运行则不需要任何改变CLR会保证所有的异常仍然按照以往的方式处理。 其次对于那些使用了.NET Framework 4.0 但又想自己处理这些导致程序状态崩溃的异常微软同样提供了选择他们在.NET 4.0中增加了一个新的命名空间System.Runtime.ExceptionServices这里面有个特性类叫做HandleProcessCorruptedStateExceptionsAttribute你只需要在相应方法上添加这个属性CLR就会把所有的异常处理交给你做就像以前一样。e.g. 代码 // 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 e) // 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. 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; } //当然要注意的是这个特性只能应用在方法上。 总结 异常处理常常是程序员心中的一块心病尽管微软认为自己得为纵容程序员滥用异常捕获负责然后添加了这个新的异常处理机制不过在他们看来那种catch(Exception e)的行为仍然是不对的。他们认为异常的出现表明当前程序的状态出现了问题而程序员应当清楚这些错误的状态所造成的后果所以程序员应当捕获具体的异常并作出正确的处理而不是因为偷懒或者省事去简单处理所有异常。 参考资料 Handling Corrupted State Exceptions 作者Andrew Pardoe 原文地址http://msdn.microsoft.com/en-us/magazine/dd419661.aspx
