關於異常的設計

在我本身搭建的開發框架中有設計這麼兩種異常,以下:java

1.業務邏揖異常程序員

/**
 * 業務邏揖異常
 * @author lenovo
 * 
 *
 */
public class ServiceException extends Exception {
	public ServiceException(String msg) {
		super(msg);
	}
}

2.非業務邏揖異常(通常是數據異常或系統異常等)
數據庫

/**
 * 非業務邏揖異常
 * @author lenovo
 *
 */
public class FaultException extends RuntimeException {

	public FaultException(String msg) {
		super(msg);
	}
}

舉個例子,好比登陸的的業務邏揖:app

public class UserService {
    .....
    public User login(String username, String password) throws ServiceException {
        User user = null;
        //根據帳號獲取用戶對象
        List<User> users = userDao.queryByUsername(usernmae);
        if (!users.isEmpty()) {
            if (users.size() > 1) {
                //根據用戶名可查到1個以上的用戶,這明顯是有髒數據存在,屬於不可預料預知的異常,此處應該拋出非業務邏揖異常
                throw new FaultException("數據有問題,存在1個以上同用戶名的用戶!");
            }
            user = users.get(0);
            if (!user.getPassword.equals(password)) {
                //密碼不正確,此處應該拋出業務邏揖異常
                throw new ServiceException("密碼錯誤");
            }
        } else {
            //用戶不存在,此處應該拋出業務邏揖異常
            throw new ServiceException("用戶名不存在");
        }
        return user;
    }
}

這個例子中,象用戶名不存在和密碼錯誤屬於可預知的異常,屬於正常的將會,因此拋出業務邏揖異常,而根據用戶名可查出一個以上的用戶這種狀況,正常狀況下是不該該出現的,說明數據庫中存在有髒數據,這種狀況不該該是可預知的狀況,程序員不該該去處理這種異常,因此此處應該拋出非業務邏揖異常。框架

固然也能夠經過返回狀態碼的方式來處理業務邏揖的異常狀況,好比:性能

/*
*由於通常登陸後都須要返回用戶對象,因此這邊須要特地寫一個類來封裝用戶類和狀態碼
*/
public class ResultWrapper {
    private User user;
    //1-表示正常,2表示用戶名不存在,3表示數據異常,.....(固然這邊也能夠用枚舉來處理)
    private int resultCode;
    //get set方法
    .....
}
public class UserService {
    .....
    public ResultWrapper login(String username, String password) throws ServiceException {
        ResultWrapper result = new ResultWrapper();
        User user = null;
        //根據帳號獲取用戶對象
        List<User> users = userDao.queryByUsername(usernmae);
        if (!users.isEmpty()) {
            if (users.size() > 1) {
                //根據用戶名可查到1個以上的用戶,這明顯是有髒數據存在,屬於不可預料預知的異常
               result.setResultCode(3);
            }
            user = users.get(0);
            if (!user.getPassword.equals(password)) {
                //密碼不正確
                 result.setResultCode(4);
            }
            result.setResultCode(4=1);
            result.setUser(user);
        } else {
            //用戶不存在,此處應該拋出業務邏揖異常
            result.setResultCode(2);
        }
        return result;
    }
}

這也是一種處理方式,具體使用見仁見智了,由於使用異常確實代價比較大(性能上的代價,java語言中處理異常的性能代價),但我仍是比較喜歡使用異常的方式來處理業務邏揖異常,主要是基於如下緣由:spa

  1. 主線比較明確,使用異常來處理業務邏揖能夠突出主線,好比登陸的場景,正常狀況下就是使用名密碼登陸成功,而若是使用狀態碼來區分的話從業務層面上來講這幾種狀態都是平級的,最後都是經過return一個結果回去。設計

  2. 代碼比較簡潔,使用異常來處理省了一個外層的包裝ResultWrapper,這邊只是一個例子,正常項目若是要用這種方式的話就會產生很是多的包裝類的,而用異常只須要兩個異常類便可code

  3. 調用方處理簡單,好比在Action中調用的話,程序員就不須要寫一堆的if else了,只須要catch一下ServiceException便可(FaultException是繼承RuntimeException的不須要特地的catch)
    orm

相關文章
相關標籤/搜索