异常,为我们处理非正常的业务流程提供了很好的解决方案,如果你有过dbase、c、pascal等过程式语言开发的经历,你一定会深刻体会到,异常机制给你的代码可读行、可维护性带来的好处,同时,程序的健壮性也得到了增强。
在 java项目中,异常设计要注意下面的几点。
一、自定义异常父类的选择
A、自定义异常的父类,可以选择为RuntimeException或Exception。RuntimeException是运行时异常,你可以选择它来做为你的异常父类,因为这种异常不受到编译器检查,因此,给予了程序员很大的灵活性,程序员可以处理这种异常,也可以不处理(实际上并不是不处理,而是不立即处理,等到一个合适的地方再进行处理)。选择RuntimeException作为父类,是很多框架常采用的,如果你是做底层框架的,可以选择 RuntimeException。
B、业务层异常,一般选择Exception作为父类,因为业务层异常比较重要,一般都是要由调用者进行处理或者是要告知调用者会发生这种异常。如果你的代码是提供给第三方厂商用的,业务层封闭统一的异常就显得非常的有必要。这类异常会强制要求程序员进行处理(异常转译或继续声明抛出),程序完整性、健壮性得到了加强。
二、业务层自定义异常结构的设计
A、业务层自定义异常可以考虑按子系统来划分,也就是说,每一个子系统(模块)都有自己的异常定义,每个子系统自己维护自己的,统一向调用者抛出。
B、根据业务类型,从逻辑上划分异常类型,比如:权限相关的,安全相关的,数据库相关的等等。
总的来说,这两种自定义异常也可以混合使用,因为有的时候,子系统(业务模块)本身就是从逻辑上进行划分的。
三、异常结构定义
异常类的父类选定后,再定义自己的异常结构。一般的异常类中,要定义这么一些东西。
A、描述字符串,说明异常的起因,或说明等。
B、异常码。定义一个int或String类型的异常码,异常码在整个系统中统一定义,根据异常继承结构,异常码也可以定义得有层次结构。异常码在大的系统中比较常见,Oracle ,Sqlserver等数据库产品中,或华为、中兴的一些驱动api中。
C、定义一个Throwable的成员变量,用以封装异常结构链。
D、定义无参数、有参数(String,Throwable)的构造方法。
四、在WEB三层模型中,异常的处理
在经典的三层架构模型中,通常都是这样来进行异常处理的:
A、持久层一般抛出的是RuntiomeException类型的异常,一般不处理,直接向上抛出。
B、业务层一般要封装自定义异常,统一向外抛出(这里要注意,如果用spring在业务层管理异常,一定要配置好异常回滚类型,因为spring默认只回滚RuntiomeException类型的)。我也见过一些想省事的人,业务层也不定义任何异常,也不进行try catch,如果业务层出现异常将在表现层进行处理及页面跳转。
C、表现层必须要处理业务层的异常,以正确向客户报告系统出现的问题,这里面是最后一道异常处理的地方。我也见过有懒人在业务层都不处理,直接在web.xml中配置errorPage的,但不建议这么做。
用好异常,对于项目的可维护性、健壮性都有极大的好处,当然,异常也不是万能的,在有些项目中并不适用,比如:纯算法项目,对性能要求极高的项目等,因为异常栈会对系统性能有一定开销,在这些项目中,最后还在老老实实用方法的返回值去标识方法执行的结果,用if else去处理业务逻辑中的非正常情况吧。