DAO中的异常处理

只有在可以合理地预期调用者可以处理异常时，DAO 接口中的方法才应该抛出检查过的异常。如果调用者不能以有意义的方式处理这个异常，那么考虑抛出一个未检查的(运行时)异常。
如果数据访问代码捕获了一个异常，不要忽略它。忽略捕获的异常的 DAO 是很难进行故障诊断的。
使用链接的异常将低级别的异常转化为高级别的异常。
实际它所描述的是应用级异常和运行期异常必须分别对待。
   为什么要区别对待呢？ 实际上无论是应用级别异常还是系统级别异常我们都需要去处理的，并且最终反馈给调用客户端一定的信息。
   不同的异常对应不同的信息，应用级别异常通常我们知道如何去处理以及给客户什么最终反馈信息，这时候我们可以参考你的例子程序中的MessageDAOException，它所表明的就是我知道这是个什么样的异常，以及告诉客户端响应的信息，但是运行期异常通常我们就无法预料，这时候我们通过基层RuntimeException以截获这类异常，一旦catch到就抛出去，这样调用端可以用这个异常来反馈给最终客户端一些信息， 比如，系统出现不可预料的异常、系统当机等。如果你截获了，并且忽略了这类异常显然对于调用者来说是致命的：客户端无法知道到底出什么情况了！


如何使DAO 更容易使用、更健壮及更易于维护，在实现 DAO 模式的异常处理时，一般我们都会考虑下面的问题：
1 DAO 的公共接口中的方法是否抛出检查过的异常？如果是的话，抛出何种检查过的异常？
2 在 DAO 实现类中如何处理异常？
在网上曾看到过一篇文章说，遵从以下这些原则可以极大地改进您的DAO ：
1 DAO 方法应该抛出有意义的异常。
2 DAO 方法不应该抛出 java.lang.Exception ，不要让DAO方法传递关于底层问题的任何信息。
3 DAO 方法不应该抛出 java.sql.SQLException ，它是一个低级别的 JDBC 异常。一 个 DAO 应该力争封 装JDBC 而不是将 JDBC 公开给应用程序的其余部分，这本书就是通过使用ORM工具来做到这一点的。
4 只有在可以合理地预期调用者可以处理异常时，DAO 接口中的方法才应该抛出检查过的异常。如果调用者不能以有意义的方式处理这个异常，那么考虑抛出一个未检查的(运行时)异常。
5 考虑定义标准 DAO 异常类，在这里书中是通过自定义一个异常体系来实现的，当然我们也可以使用Spring框架 提供的一套预定义的 DAO 异常类。
对于这本书的小例子而言，很好地体现了上面的那些原则，达到了极大地改进DAO地目标，具体是这样做的：
首先是自定义了一个MessageException 对象，它是其它业务异常的父类，也是整个项目所有自定义异常的根。书中提到，之所以这样进行处理，是采取了整个Java系统在设计的时候使用的单根 (Object对象)的处理方法。因为在业务处理过程中，出现的问题都是由用户或者系统的原因造成的，而且是无法预先知道的，只有在运行时才能发现这些问 题，所以在这个定义的异常对象中继承了RuntimeException，如清单8

public class MessageException extends RuntimeException

...{
/** *//**
* Generated serialVersionUID
*/

private static final long serialVersionUID = 6905209869067708768L;

public MessageException( String message )
...{
super( message );
}
}

书中提到说在上面这个异常中没有定义任何特殊的方法，对于复杂的系统需要增加一些自己的方法，以便于进行数据和状态信息的传递。另外两个异常对象 MessageDAOException，MessageAuthorityException则属于具体的业务异常对象了。 MessageDAOException表示进行持久化时产生的异常，例如根据留言的ID去查找留言的信息，如果该留言对象不存在，那么就会抛出这个异 常。实现方法如清单9

public class MessageException extends RuntimeException
...{
/** *//**
* Generated serialVersionUID
*/
private static final long serialVersionUID = 6905209869067708768L;

public MessageException( String message )
...{
super( message );
}
}

MessageAuthorityException是与权限相关的异常，在进行权限校验失败时抛出这个异常。实现方法如清单10

public class MessageAuthorityException etends MessageException
...{
private static final long serialVersionUID = 1L;

public MessageAuthorityException(String message)
...{
super(message);
}

在这里，定义不同的异常是使我们可以把注意力放在应用级的层次上，捕获异常后可以采取不同的处理方法，进行不同的处理：

下面这个代码片段是来自清单 3. 的，这里在删除一条留言信息的时候，就调用了刚才定义的MessageDAOException

/**

* 删除留言信息

*

* @param id

* 要删除的留言信息的ID值

* @param userId

* 执行删除操作的用户ID

*/

public void deleteMessage(String id， String userId)

{
Message msg = getMessage(id);

if (msg == null)
{
throw new MessageDAOException(找不到你所要删除的留言!);
}
if (!msg.getUser().getId().equals(userId))
{
throw new MessageDAOException(你不能删除别人的留言！);
}
deleteObject(msg);
}

这 些就是定义系统异常时的处理结构，它的主导思想就是依据对异常处理方法的不同而定义不同类型的异常，依据每个异常所包含的信息不同来定义不同类型的异常。 在下一个笔记里就是讨论如何实现从一个工厂类里获得DAO接口的实现类，将会用到IOC容器的一种实现形式DI，这里不是采用Spring的IOC容器而 是自己实现一个简单的，当然，这种做法的目的，其实就是帮助我们更好地理解DIP，从而也对Spring的bean工厂有更好地理解～～～