关于Exception

导读：
　　实际上在系统正常运行的时候，应该是没有异常的。所有正常运行中被发现的异常，都应该被if else之类的判断分支所替代。
　　因此，最终只要在表现层try catch就可以了。在表现层try catch的时候，记录下exception中的stack frames就可以了。要是有了stack frames都还分析不出问题，那就表明系统设计有问题。
　　我的以上观点可以从微软的示范代码中得到验证。
　　我们公司的开发流程是：没有任何try catch的情况下进行开发。然后测试。在单元测试和联合测试都完成之后，再加上try catch进行最终测试。（在表现层加上try catch只是为了避免“客户使用中出现的我们不曾遇到的”意外情况）。try catch应用在底层模块的一个主要原因是为了保证resource safe。而我们通常是用using()关键字来保证resource safe。
　　或者修改一下我的措辞，我们不会在底层就吞食掉exception。因为我们知道using()其实也是try catch，不过using()在catch之后立刻将原来那个exception原样抛出。
　　微软自己的类库曾经很自信的吞食了一些exception，于是微软的类库现在有了一些奇怪的特性：比如从类库返回不恰当的提示信息，比如类库里面诡异的弹出一个莫名其妙的对话框。Exception的处理中有一个奇怪的原则：谁能修正或者了解这个exception，谁才能吃掉这个exception。
　　实际上如果谁能够修正或者了解这个exception，那么他通常也就有能力避免这个exception的出现。
　　一般性的业务错误，比如用户名密码错误，比如用户输入错误，比如一般性业务逻辑错误，我们都是通过代码进行逻辑判断的。不会抛出异常。只有那些我们没有考虑到的情况才会导致异常。而实际上我们在表现层catch到exception之后，几乎只有一种处理方式：操作失败，请联系系统管理员。
　　然后系统管理员会查看系统的错误日志，解决这个问题。transaction需要roll back操作的时候，try catch也是会使用的。但是随后必须将这个异常原样的throw出去。
　　微软的Enterprise Library 2005共有1319个代码文件。你们猜猜里面一共有多少个try？
　　答案是268。而且这268个try当中大概有一半是在Test project里面。而且剩下那一半中有很多try是只有fininally没有catch的。
　　现在还有谁觉得try是件很好玩的事情吗？
　　大家再猜猜在Enterprise Library 2005的1319个代码文件里面，派生的Exception class有多少个呢？
　　答案是9个，分别是：AuthorizationRuleNotFoundException SyntaxException UserNotFoundException MockDebugUtilsThrowsNonSecurityException MockDebugUtilsThrowsSecurityException LoggingException ConfigurationDependencyException ExceptionHandlingException MockException这九个派生的exception class当中，有三个是在test project当中的。实际上类库里面的派生exception class只有六个。而且从我的眼光看来，即使是剩下的这六个派生exception class用得也是比较勉强的。
　　还有谁坚持派生大量的exception class是个好主意吗？

以上内容属网上转载,如有侵权,请来信告知,我们将立即删除。
本文转自
http://www.dotnet-tech.cn/post/7.html