异常，为我们处理非正常的业务流程提供了很好的解决方案，如果你有过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去处理业务逻辑中的非正常情况吧。