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