Java如何处理异常
异常
受检异常
?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) throws DAOException;
