1. JDBC API 异常处理存在哪些痛点？
1.使用检查型异常
JDBC API 使用检查型异常，以至于开发者在使用时须强制捕捉处理这些异常。然而在多数的情况下，引发异常的原因往往是不可修复的 ，开发者除了能在try/catch记录异常信息外，并没有做多少实质性的工作。因此检查型异常除了限制开发者的自由外，并没有提供什么有价值的东西，实在是用也用不得，丢也丢不得。
2.体系单一，语义模糊
引发JDBC异常的原因有很多，如数据库连接失败、SQL语法错误、结果集关闭、列索引无效等等，而JDBC API 大多以SQLException一概而论，异常体系比较单一，语义层面上也无法准确表达引发异常的大体原因。
3.喧宾夺主，破坏了程序的整洁和优雅。
使用JDBC API 需要编写大量的try/catch来处理检查型异常，让人难以忍受的是，一堆堆异常处理代码喧宾夺主地侵入到业务代码中，破坏了代码的整洁和优雅。
2.什么是Spring JDBC 异常体系？
针对以上问题，Spring为开发者提供了一整套完备优雅DAO异常体系，这些异常继承于DataAccessException， DataAccessException又继承于NestedRuntimeException。注意，从名字上就可以看出NestedRuntimeException是运行时异常、这意味着Spring JDBC整套异常体系都是运行时异常，开发者终于可以从无尽的try/catch八股文式代码中解脱出来，专注于业务逻辑。当然，Spring JDBC 异常体系并没有抛弃原生异常，原生异常以嵌套的方式保存在NestedRuntimeException中，开发者可使用 getCause()方法获取。
Spring JDBC以分类的手法建立了语义丰富的异常体系目录，对于大部分应用来讲，这个异常分类目录对异常类型的划分具有适当的细粒度，一方面，丰富的语义涵盖了各类引发异常的情形，使得开发者通过类名称就能大概了解异常的原因，开发者可以自由选择感兴趣的异常进行处理。另一方面，Spring JDBC 提供了异常转换器，以至于不同的持久层技术的异常体系都可以通过异常转换器纳入Spring DAO 异常体系中来，这样一来，不同持久层异常体系的阻抗因Spring JDBC 异常体系得以消除 。
图一：Spring 异常体系
图2 异常转换器结构
