Spring3的DAO框架没有抛出与特定技术相关的异常，例如SQLException或HibernateException，抛出的异常都是与特定技术无关的DataAccessException类的子类，避免系统与某种特殊的持久层实现耦合在一起。DataAccessException是RuntimeException的子类，即是一个无检测的异常，不要求代码去处理这类异常，遵循了Spring的一般理念：异常检测会使代码到处是不相关的catch或throws语句，使代码杂乱无章；
DataAccessException类的结构图
并且DataAccessException是NestedRuntimeException的子类，是可以通过NestedRuntimeException的getCause（）方法获得导致该异常的另一个异常。
CleanupFailureDataAccessException
一项操作成功地执行，但在释放数据库资源时发生异常（例如，关闭一个Connection）
DataAccessResourceFailureException
数据访问资源彻底失败，例如不能连接数据库
DataIntegrityViolationException
Insert或Update数据时违反了完整性，例如违反了惟一性限制
DataRetrievalFailureException
某些数据不能被检测到，例如不能通过关键字找到一条记录
DeadlockLoserDataAccessException
当前的操作因为死锁而失败
IncorrectUpdateSemanticsDataAccessException
Update时发生某些没有预料到的情况，例如更改超过预期的记录数。当这个异常被抛出时，执行着的事务不会被回滚
InvalidDataAccessApiusageException
一个数据访问的JAVA API没有正确使用，例如必须在执行前编译好的查询编译失败了
invalidDataAccessResourceUsageException
错误使用数据访问资源，例如用错误的SQL语法访问关系型数据库
OptimisticLockingFailureException
乐观锁的失败。这将由ORM工具或用户的DAO实现抛出
TypemismatchDataAccessException
Java类型和数据类型不匹配，例如试图把String类型插入到数据库的数值型字段中
UncategorizedDataAccessException
有错误发生，但无法归类到某一更为具体的异常中
Spring的DAO异常层次是如此的细致缜密，服务对象能够精确地选择需要捕获哪些异常，捕获的异常对用户更有用的信息，哪些异常可以让她继续在调用堆栈中向上传递。
于是，我们在dao中只需要抛出这个运行时异常，我们就可以在
/** * 根据时间获取日KPI数据 * @param date 日期 * @return */ public List<KPIDataBean> getKPIOfDayDataByDate(String date) throws DataAccessException;
并在它的实现类中也抛出这么个异常。
这样，在调用这个方法的时候，我们捕获这个异常即可：
try {
list = kpiDao.getKPIOfDayDataByDate(date);
} catch(DataAccessException e) {
System.out.println("test:" + e.getMessage());
}这样就可以捕获相应的异常了。
这是打印出来的信息：
test:nested exception is org.apache.ibatis.exceptions.PersistenceException: ### Error querying database. Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Communications link failure
下图是Spring3.0中定义的异常结构图，如下图：
推荐阅读《Java合理异常设计》
点击学习 MyBatis 教程，了解更多的 MyBatis 知识！
