缥缈止盈
这个很容易理解啊.打个简单的比方. 现在做一个登录有用户不存在/密码错误... 这些错误类型, 如果你直接使用RuntimeException 代码要写成这样.
throw new RuntimeException("user not found"); // 用户不存在
throw new RuntimeException("password not match"); // 密码错误
捕捉异常
try {
// ...逻辑
} catch(RuntimeException e) {
if("user not found".equals(e.getMessage())) {
// ...逻辑
} else if("password not match".equals(e.getMessage())) {
// ...逻辑
}
}
反之自定义异常实现如下:
throw new UserNotFoundException("user not found"); // 用户不存在
throw new PasswordNotMatchException("password not match"); // 密码错误
捕捉异常
try {
// ...逻辑
} catch(UserNotFoundException e) {
// ...逻辑
} catch(PasswordNotMatchException e) {
// ...逻辑
}
通过message判断处理异常逻辑有很多弊端, 比如message是动态的, 那将无法准确的处理.当然我们也可以定义一个通用的异常类型, 通过业务码去判断会更加准确, 同时也会减少异常类型的定义, 减少代码的冗余. 下面有一段kotlin代码, 目前我是使用的这种处理方式.
interface BizCode {
val code: Int
val msg: String
}
enum class BizCodes(override val code: Int, override val msg: String): BizCode {
// ====================================================== //
// 公共错误码 0 - 999 //
// ====================================================== //
/**
* 未知错误.
*/
C_0(0, "未知错误"),
/**
* HTTP Request 参数错误.
*/
C_999(999, "HTTP Request 参数错误"),
// ====================================================== //
// client 错误码 1000 - 1999 //
// ====================================================== //
/**
* 未发现指定 client_id 客户端记录.
*/
C_1000(1000, "未发现指定 client_id 客户端记录"),
C_1001(1001, "client_secret 不匹配"),
// ====================================================== //
// user 错误码 2000 - 2999 //
// ====================================================== //
/**
* 未发现指定 email 的用户.
*/
C_2000(2000, "未发现指定 email 的用户"),
C_2011(2011, "password 不匹配"),
//
;
override fun toString(): String {
return "[$code] $msg"
}
}
class BizCodeException : RuntimeException {
val bizCode: BizCode
constructor(bizCode: BizCode) : super(bizCode.toString()) {
this.bizCode = bizCode
}
constructor(bizCode: BizCode, e: Exception) : super(bizCode.toString(), e) {
this.bizCode = bizCode
}
override fun fillInStackTrace() = this
}