实际上在系统正常运行的时候，应该是没有异常的。所有正常运行中被发现的异常，都应该被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是个好主意吗？