尽量给自己应用量身定制一套异常类，反应各种不同的错误，以便构建统一的、健壮的API。
应用每层定义统一的接口异常类，而不是简单抛出来自实现遇到的异常，否则实现一经改变，原来的异常可能会变化，接口可能也需要跟着更改。
给每个异常和错误定义统一的标识，如错误码，方便根据错误码找到详细的错误信息以及支持国际化，方便统一的异常处理框架。
抛出异常：
如果一个异常是致命的，不可恢复的，或者调用者去捕获它没有任何益处，使用unChecked异常。
如果一个异常是可以恢复的，可以被调用者正确处理的，使用checked异常。
在使用unChecked异常时，必须在在方法声明中详细的说明该方法可能会抛出的unChekced异常，由调用者自己去决定是否捕获unChecked异常
异常信息中精确描述何种操作导致失败（如果有，最好包括参数数据），以及可能的恢复或者处理方法。
记录异常：
异常应该在最初产生的位置记录！
如果必须捕获一个无法正确处理的异常，仅仅是把它封装成另外一种异常往上抛出，不必再次把已经被记录过的异常再次记录。
如果捕获到一个异常，但是这个异常是可以处理的，则无需要记录异常
捕获到一个未记录过的异常或外部系统异常时，应该记录异常的详细信息
给应用定义统一的异常记录类，增加额外的应用信息到异常日志。
处理异常：
异常捕获时由子类到父类过滤逐级分开处理。
try{..}块最好只包含可能抛出异常的语句，语句越少越好。
调用的函数可能抛出unchecked异常时，即使不捕获异常，也应该注意使用try{...}finally{...}释放该释放的资源；相对checked异常，我们都记得用try{...}catch{...}finally{...}。