基类抛出异常的问题

这次项目的DAO是针对接口编程，bo都是通过调用DAO接口对数据库进行操作。
所有DAO异常的基类位DAOException。

下面是其中的一个DAO interface的举例代码

public interface UserDAO {
	public void addUser(User user);
		throws DAOException;
	public void updateUser(User user);
		throws DAOException;
	public void removeUser(User user);
		throws DAOException;
	public User findByUserID(String userID);
		throws DAOException;
		
}

但在具体的时候的时候，很多函数并没有抛出DAOException，（很多情况下我都是抛出的RuntimeException
但是因为interface中每个函数都有DAOException 抛出的定义，所以在bo中使用DAO的时候，即使这个DAO函数的具体实现并没有抛出DAOException，bo中依然需要使用try。。catch。。finally的结构来处理。

我觉得看起来很不舒服，于是想把interface重构一遍，在只有可能会抛出DAOException的函数后面定义DAOException
但对于这种重构我有一个疑虑，就是我需要猜测在某个函数的未来实现中不会抛出异常，这种预测具有不确定性，如果某个预测不准确，将来还要对interface进行修改，这样总是感觉不舒服。
各位大大给点意见。

数据操作中, 数据库连接异常的这种情况总存在吧.

谈谈个人的一些理解。
基本的crud操作的异常抛出是不确定的，因为存在并发，你不知道何时哪个线程会锁表，哪个线程又会删除你正在操作的数据，除非你设定最严格的事务隔离级别，即使这样也会有事务超时、网络断线、数据库当机的异常发生。所以抛出checked Exception是第一选择－－你必须强迫你的客户去捕捉异常并处理之。
第二选择－－你也可以自动处理，抛出特定的runtime Exception，然后在filter中捕捉。

连接异常全部都是抛出runtimeexception,在我们的系统中不对这种情况考虑恢复处理。

恩。网络断线，数据库当机这种情况我们都是抛runtime exception的。不需要上层的程序员对这种异常进行任何处理。
runtime exception的处理是传递到error中做了某些错误显示工作而已。

pufan，我是否可以把你的意见理解成只针对现在在hibernateimpl实现的dao中会抛出异常的Dao interface的函数中定义checkedexception。不需要在前期过度设计。
简化上层程序员的工作量，到后期如果有对DAO interface的其它XXXimpl实现中出现了需要抛出checked exception 的情况，再进行重构就可以了。

其实全部抛出RuntimeException比较好。即使你抛出了CheckedException，又有多少情况你会不显示错误给用户看而去捕捉异常并做事务的重新提交那。
即使需要恢复处理，捕捉特定的RuntimeException进行事务的重新开始也是可以选择的办法。

如果抛出的checkedException通常都是表示业务逻辑上的错误，比如duplicaterecord
这种exception 在dao抛出后bo是需要强迫处理的，因为我我们要求bo的程序任何抓到的异常都不允许简单的使用ex.printtrackstack（）来敷衍，必须处理。
所以如果DAO中全部抛出checked是不可能的。
我同意robbin在文章中提的使用checked表示业务错误（有时候就是分枝）的观点。