谈谈异常处理与web应用中的异常体系结构设计（一）

我想，每一个java开发人员都知道通过 try/catch/finally来进行异常处理，但是你有没有和我一样，在某个时候觉得异常处理是如此的让人沮丧，将原本清晰的代码和逻辑折腾的面目全非的感觉呢？最让我深刻感受到这一点的是用jdbc的时候，当我看着写出来的代码，我很疑惑的想，我不是在写业务逻辑，我是在给异常处理当牛做马！！！


不管那一本讲授编程语言的书籍中，不管是c++的，java的，还是与他们完全不同的语言，如erlang，都会有一章专门讲异常处理，并且我们被告知异常处理是程序不可缺少的一部分，是写出健壮程序必须的。虽然书中给出的例子看起来异常处理并不难，语法，语义都没有什么难以理解的地方。但是当我们真正靠自己的双脚来丈量地球的时候，我们会发现，原来异常处理和我们如影随行，并且很多时候我们在被异常群殴。虽然我们很恼火，但是却好像毫无办法。我们很难在重重异常的包围中，让自己像一个虔诚的教徒一样，保持自己的绅士风度，保持优雅的举止。虽然这个时候你可能具备了一定的经验，也深深的阅读了比如java 核心编程，java编程思想，更进一步，你还对于模式有着一定的掌握，但是异常就像空气一样，时刻环绕着你。
我也是如此，所以才有这篇文章，我想把自己的想法和更多的人交流，分享，并且希望通过这些努力能有一些效果。所以，这篇文章不是一个解决方案，只是一些想法，欢迎各位拍砖。

一.为什么异常会这么深的破坏我们代码的优雅性，让我们很疲惫。

因为我们的代码可能会出现多种不同的异常，这些异常都需要被处理。


因为这个原因，我们的代码往往会是下面这样的。


try{
statementblock;
}
catch(ExceptionType1 e)
{
try{
statementblock
}
catch(ExceptionType4 e)
{

}

}
catch(ExceptionType2 e)
{
e.printStackTrace();
throw new UserDefinedException;
}
catch(ExceptionType3 e)
{
e.printStackTrace();
throw new UserDefinedException;

}
finally
{

}

现在有很多的公司已经开始采用持续集成环境了，我们的代码的圈复杂度在这种情况下肯定让人头痛。所以，能够以一种统一的，简洁的方式来完成异常处理对于我们的工作有着很重要的意义。接下来，我给出我在实际工作中采用的方法。由于我们给公司打工，所以我们的工作成果是公司的，版权也是公司的，这里我贴出的代码是一个示意性的，把意思表达到即可，欢迎拍砖。


先说一下要满足的要求：

（1）这个处理方式必须满足使用上的方便性

（2）必须不丢失异常栈信息

（3）要满足异常消息/异常码准确表达异常位置的要求

（4）要能够方便的记录日志

（5） 多层调用不发生覆盖或着重复捕获


我们的项目里头自己定义了一个异常类作为应用自己的异常，暂且称为ApplicationException吧，但是很遗憾，这个类定义的很差劲，不接受将异常作为参数传入。于是修改之，目的是记录异常栈的信息。同时，建立一个ExcetpionUtil类，其中有一个 transtoApplicationException地方法，


public static ApplicationException transtoApplicationException(String errorMsg, class<T> clazz,Exception e)
{
if(isApplicationException(e))//判断该异常是否是已 //经经过捕获处理的
{
throw e;
}
else
{

Logger.getLog(clazz.getName()).

error(getStackTrace(e))//将异常栈输出到日志
throw new ApplicationException(errorMsg,e); //抛出转换后的异常
}
}
上面的代码还有很多问题，但是，它也具备了一些好的特性。它的使用场景是应用自身之定义了一种异常，当应用的异常有多重的时候，需要通过父类判断是否被捕获过。但是，他至少可以并且也做到了让异常分支在代码中保持很少量的要求，并且，对于每一个应用中的方法都可以正确无误的个给出一个异常码或者消息而绝对不会被覆盖或者受到干扰，不管中间经过了多少层调用。

 

 

 有人看，但是没有人回复和拍砖，不管，第一次发文章，继续坚持吧。

  昨天没写完，今天继续。目前给出的这个把那个不是一个异常体系设计的结果，而是直接面向解决问题而而得来的一个工具类，使用了这个以后，代码就会变成下面这个样子

      try{

               statementBlock;

           }

             catch(Exception)

            {

            throw   transtoApplicationException(errorMsg,e,className.class,e);

            }

 

前面提到过：对于每一个方法，这个做法可以保证方法和异常码/消息之间的唯一对应关系，这对于代码调试是有利的，因为异常报告的很准确，再加上异常栈的信息，足够了。而且，也满足了异常在最近的地方被捕获的要求。以后，你的代码中再也不需要e.printStacktrace(),不需要那么多的异常分支，不需要在调试完成后再关掉 e.printStacktrace()。

但是，这个工具虽然有用，却不支持在发生异常时释放资源的工作，也不支持不同的底层异常抛出为不同的应用自定义异常

的场景。这就需要进一步的改进。后面，会继续深入讨论关于异常处理的问题。