Thinking in Exception（Base on Alfresco）

 

Thinking in Exception（Base on Alfresco）:

 

在Alfresco中大多数Exception均继承AlfrescoRunTimeException或者直接继承RunTimeException. AlfrescoRunTimeException也是继承RunTimeException.

从Alfresco开发的角度分析，我觉得他更愿意把例如版本信息不正确，规则不正确等相关信息看作一种错误信息。在执行的过程中直接抛出，而不需要捕获。

事实上，他们的捕获是在表现层中进行捕获，然后进行业务逻辑判断。

 

我们一直都认为，RunTimeException是一种出错后的异常，由于这种异常不需要捕获，所以，如果我们定义异常，我们基本是不会考虑继承RuntimeException.而是直接继承Exception.从而在每个方法调用的时候严格的进行异常的处理。甚至有的编程规则中也明确表明，不准许出现继承RunTimeException的代码。

 

但是，同时也有一个问题摆在前面，我们在写的相当多的Exception后发现很难进行统一的管理，更多的还是进行了模糊处理，即捕获该异常的父类，然后再往上面抛，直到有人需要处理。最后的结果是到需要处理的那个地方，也不知道自己捕获到的究竟是那个子异常，而无办法处理，于是只能大致处理。

当然，我们也可以要求对有能捕获到的异常要进行很好的处理。但这里存在两个执行上的困难。

1.       我们很多情况都是先设计好父类或者接口，然后在具体到子类去继承和实现。但我们在这个时候是不能很清楚需要定义哪些异常的，但是如果我们在实现或者完成子类的时候去做，那么，势必会修改父类的内容。这很显示破坏我们期望的open-close的思路。

2.       就是我们势必会花更多的精力去处理异常，势必会导致代码里面包含这很多异常处理的代码。这很显示不是我们希望看到的设计。

所以，我们很多时候在上层又进行了统一处理。虽然逻辑上是我们在我们需要的地方处理异常，但结果确实根本没有处理好这些异常。

所以，也有人倡导在代码里不要使用Check Exception.

 

       异常最直接的理解便是例外，就是说他不属于正常逻辑。但我们在使用的时候有的情况希望有一种象异常机制一样的处理，所以，有了Check Exception.例如：

       用户权限验证，我们在做某件事情的时候，需要去判断权限，这其实是我们正常的业务逻辑。但我们在通过权限验证后，进入做后面的事情，可能在比如需要用户信息时，这个用户居然没有了，那么，这个应该算是一个异常。因为正常的情况下，这个用户是可能有的。

       但我们以前有的时候做设计的时候会这样考虑，比如我在Service层需要验证用户的权限了，在当这个验证不通过时，我希望不允许他操作，我们可能想直接把它往外面送。这个时候，虽然，这个整个逻辑是正常的业务逻辑，可能我们觉得异常的机制是我们想要的一种处理方式，就是往上面抛异常，在需要处理的地方进行处理，于是我们在项目中使用了Check Exception的概念。

 

综上所述，个人认为，这事实上是取决于我们能接受什么样的结果或者我们有什么样的需求。但大多数情况我们对异常的处理是忽略式处理，或者是转换成界面的提示方式，而不是真正去对他进行很详细的处理。如果这个情况，我个人建议使用RunTimeException的继承。如果我们确实有希望进行很详细处理的地方，那么，我们应该使用Exception的继承。

因为：反应到客户端事实上大部分是三种结果：转到错误说明页面或者还在当前页面，只是打印相关的错误信息，或者保持业务逻辑及页面的正确执行。

当然，我们如果需要考虑异常信息的国际化，那么，我么不管是定义我们Exception还是RunTimeException,都需要定义一个比较完整的处理，最好是使用资源文件式的异常信息管理。