原因是很多开发者缺乏对异常的认识和分析,首先应该明白Java异常体系结构,一种分层继承的关系,你必须对层次结构熟烂于心:
一般把Exception异常及其直接子类(除了RuntimeException之外)的异常称之为检查异常。把RuntimeException以及其子类的异常称之为非检查异常,也叫运行时异常。
对于Throwable和Error,则用的很少,一般会用在一些基础框架中,这里不做讨论。
下面针对J2EE的分层架构:DAO层、业务层、控制层、展示层的异常处理做个分析,并给出一般处理准则。
1)、DAO的接口不被异常所污染,假设你抛出了SQLException,以后要是换了Spring DAO模板,那DAO接口就不再抛出了SQLException,这样,你的接口抛出异常就是对接口的污染。
2)、DAO异常向外传播给更高层处理,以便异常的错误原因不丢失,便于排查错误或进行捕获处理。
习惯上把业务层称之为Service层或者服务层,Service层的代表的是业务逻辑,不要迷信分太多太多层有多大好处,除非需要,否则别盲目划分不必要的层,层越多,效率越差,根据需要够用就行了。
搞明白以上两个问题后再回过头看异常怎么处理,Service层通常依赖DAO,而Service层的通常也会因为调用别的非检查异常方法而必须面对异常处理的问题,这里和DAO层又有所不同,彼一时,此一时嘛!
如果是控制层中因为调用了一些非检查异常的方法,比如IO操作等,可以简单处理下异常,保证流的安全,这才是目的。
对于页面异常,处理的方式多种多样,一是不处理异常,一旦异常了,页面就报错。二是定义出错页面,根据异常的类型以及所在的模块,导航到出错页面。
另外还有特殊的处理方式,展示页面的模板可以捕获异常,并根据情况将异常信息铺到相应的位置,这样就更友好了,不过复杂度较高。
1)、对于异常处理,应该从设计、需要、维护等多个角度综合考虑,有一个通用准则:千万别捕获了异常什么事情都不干,这样一旦出现异常了,你没法依据异常信息来排错。
2)、对于J2EE多层架构系统来说,尽可能避免(因抛出异常带来的)接口污染。