异常
受检异常
FileNotFoundException
ClassNotFoundException
SQLException
IOException
非受检异常
RunTimeException
Error
原则:受检异常,如果自身不能处理就往上抛
如果资源的打开,资源的使用,资源的关闭都封装处理,那么可以抛出运行时异常RunTimeException.[Spring的DAO封装].
如果资源的打开,资源的使用,资源的关闭在方法中未处理完成,那么可以抛出受检异常FileNotFound.[java的io文件操作]
抛出受检异常还是非受检异常?
对可恢复的情况使用受检异常,对编程错误使用运行时异常或错误[未受检异常].
未受检异常:如果程序抛出未受检异常或者错误,往往就属于不可恢复的情形,继续执行下去有害无益.[你实现在所有未受检的抛出结构都应该是运行时异常的子类.]
那么何时使用受检异常?
1. 如果正确地使用API并不能阻止这种异常条件的产生。[正确的使用DAO调用,不能阻止异常条件的产生,不使用受检异常][DataAccessException]
2. 一旦产生异常,使用API的程序员可以立即采取有用的动作,这种负担就被认为是正当的.[比如服务层调用失败应该受检异常,某个服务调用失败可能不会影响其他服务的调用][XXXException]
自定义的异常应该是受检还是未受检?
有一条原则是避免不必要的使用受检异常.受检异常可以声明它抛出这些异常,并让它们传播出来.[异常传播]
那么一般我们在设计接口的时候会考虑异常吗?肯定不会,因为接口是提供给外部调用的,接口的实现保持原子性,所以对资源的操作[打开,使用,关闭]都封装在接口的实现中.那么为了避免接口污染,不抛出异常.
例子:
Spring封装的dao操作已经把Exception封装为DataAccessException,此异常为运行时异常,不是受检异常,代码会非常的优雅.当然并不是所有的DAO操作异常都抛出
DataAccessException,而是先抛出它的子类: DataIntegrityViolationException[主键重复异常], TypeMismatchDataAccessException[类型错误]等等异常,采用异常子类来封装多异常类也是不错的选择.
那么使用Spring开发,DAO层的接口可以非常清晰
那么Service层提供的接口也不需要考虑异常,因为DAO已经封装了数据库的交互,保持了DAO操作的原子性,所以Service层接口也会相当的简单.
有人可能会问,这个DAO的接口与Service的接口一模一样,你不觉得蛋痛吗?
这是个问题啊,但是在领域模型中,这是不一样的概念.不知道下面有没有大侠有更好的解决方案[求教.]
我不建议这么做,嘿嘿,有人可能会问你在挑战Spring。在具体的业务逻辑操作,比如你可能会在N多地方调用getServiceById(Long Id).如果错误信息只有在DAO层抛出,你知道哪个业务调用出错了,所以采用异常往外抛的话,你会看到一条线.
DAOException[…],ServiceException[…],Action[…].一条很清晰的异常链.如此的话,你的DAO接口,Service接口设计就要如下:
如果采用这种方式抛出异常,那么在DAO层,Service层都必须封装Exception,无原无故多这些try..catch实在是蛋痛,不知道有没有哪位大侠有更好的建意。
受检异常
FileNotFoundException
ClassNotFoundException
SQLException
IOException
非受检异常
RunTimeException
Error
原则:受检异常,如果自身不能处理就往上抛
如果资源的打开,资源的使用,资源的关闭都封装处理,那么可以抛出运行时异常RunTimeException.[Spring的DAO封装].
如果资源的打开,资源的使用,资源的关闭在方法中未处理完成,那么可以抛出受检异常FileNotFound.[java的io文件操作]
抛出受检异常还是非受检异常?
对可恢复的情况使用受检异常,对编程错误使用运行时异常或错误[未受检异常].
未受检异常:如果程序抛出未受检异常或者错误,往往就属于不可恢复的情形,继续执行下去有害无益.[你实现在所有未受检的抛出结构都应该是运行时异常的子类.]
那么何时使用受检异常?
1. 如果正确地使用API并不能阻止这种异常条件的产生。[正确的使用DAO调用,不能阻止异常条件的产生,不使用受检异常][DataAccessException]
2. 一旦产生异常,使用API的程序员可以立即采取有用的动作,这种负担就被认为是正当的.[比如服务层调用失败应该受检异常,某个服务调用失败可能不会影响其他服务的调用][XXXException]
自定义的异常应该是受检还是未受检?
有一条原则是避免不必要的使用受检异常.受检异常可以声明它抛出这些异常,并让它们传播出来.[异常传播]
那么一般我们在设计接口的时候会考虑异常吗?肯定不会,因为接口是提供给外部调用的,接口的实现保持原子性,所以对资源的操作[打开,使用,关闭]都封装在接口的实现中.那么为了避免接口污染,不抛出异常.
例子:
Spring封装的dao操作已经把Exception封装为DataAccessException,此异常为运行时异常,不是受检异常,代码会非常的优雅.当然并不是所有的DAO操作异常都抛出
DataAccessException,而是先抛出它的子类: DataIntegrityViolationException[主键重复异常], TypeMismatchDataAccessException[类型错误]等等异常,采用异常子类来封装多异常类也是不错的选择.
那么使用Spring开发,DAO层的接口可以非常清晰
/**
* 根据服务id获取服务信息
**/
Public ServiceDO getServiceById(Long id);
那么Service层提供的接口也不需要考虑异常,因为DAO已经封装了数据库的交互,保持了DAO操作的原子性,所以Service层接口也会相当的简单.
/**
* 根据服务id获取服务信息
**/
Public ServiceDO getServiceById(Long id);
有人可能会问,这个DAO的接口与Service的接口一模一样,你不觉得蛋痛吗?
这是个问题啊,但是在领域模型中,这是不一样的概念.不知道下面有没有大侠有更好的解决方案[求教.]
我不建议这么做,嘿嘿,有人可能会问你在挑战Spring。在具体的业务逻辑操作,比如你可能会在N多地方调用getServiceById(Long Id).如果错误信息只有在DAO层抛出,你知道哪个业务调用出错了,所以采用异常往外抛的话,你会看到一条线.
DAOException[…],ServiceException[…],Action[…].一条很清晰的异常链.如此的话,你的DAO接口,Service接口设计就要如下:
/**
* 根据服务id获取服务信息
**/
Public ServiceDO getServiceById(Long id) throws DAOException;
如果采用这种方式抛出异常,那么在DAO层,Service层都必须封装Exception,无原无故多这些try..catch实在是蛋痛,不知道有没有哪位大侠有更好的建意。