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);

那么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实在是蛋痛，不知道有没有哪位大侠有更好的建意。