由于天天写bug,代码里各个地方充斥着对异常的处理,有时候思路被卡住:这个地方是该抛异常呢,还是我就地解决?是抛出受检异常(Exception)还是抛出非受检异常(RuntimeException)呢?这个异常带不带状态码啊?常常在想,有没有什么好的定律可以指导我优雅地处理Java异常。
目前项目中常见的抛异常的做法是
public interface IExceptionCode {
String name();
String getMessage();
}
public enum AccountExceptionEnum implements IExceptionCode {
// 枚举名就是状态码
ACCOUNT0001("验证码错误");
private String message;
AccountExceptionEnum(String message) {
this.message = message;
}
@Override
public String getMessage() {
return message;
}
}
public class ServiceException extends Exception {
private String code;
public ServiceException(String message) {
super(message);
}
public ServiceException(String code, String message) {
this(message);
this.setCode(code);
}
public ServiceException(String code, String message, Throwable cause) {
super(message, cause);
this.setCode(code);
}
public ServiceException(String code, Throwable cause) {
super(cause);
this.setCode(code);
}
public void setCode(String code) {
this.code = code;
}
public String getCode() {
return this.code;
}
}
// 定义特定异常
public class AccountServiceException extends ServiceException {
public MarsServiceException(String message) {
super(message);
}
public MarsServiceException(IExceptionCode message) {
super(message.getMessage());
super.setCode(message.name());
}
}
抛出带状态码的特定受检异常:
throw new AccountServiceException(AccountExceptionEnum.ACCOUNT0001);
这些特定ServiceException
类型的异常都抛到了前端,异常序列化后的字符串:
{
"code": "ACCOUNT0001",
"message": "验证码错误",
"data": null
}
每次要抛出一个业务异常的时候,都要写一个code和message,当业务流程校验比较复杂的时候,就要在AccountExceptionEnum
里定义很多的code、message。感觉不爽的是,这大量的code码没有产生业务意义,觉得很冗余。还有项目中异常的使用也比较乱。
那来给寄几定义几个使用异常的不定法则吧,从此寄几再也不用担心我使用异常了。
一、业务性api、open api、soa接口层抛出特定的受检(Exception)异常,不抛非受检异常(RuntimeException)
api接口和soa接口声明受检异常,抛出特定受检异常(比如上面定义的AccountServiceException
),这样controller层对异常的序列化也比较方便,清晰明了,就告诉你我会抛出这种类型的异常,你小心点。
二、状态码有业务意义,才抛出带状态码的异常
1. 开放平台的open api接口
开放平台的open api接口产生的异常都要带上状态码,以便第三方平台调用的识别。
2、一般业务系统api接口
将项目中的异常分成两类,有状态码和没有状态码。将状态码抛出去一定得是有业务意义的,不然就直接将错误message抛给前端就好了。秉承的原则就是不要写一点多余的代码。
3、soa接口
服务之间的调用,原则和2中所说一样。
4、业务方法
只抛带错误message的异常。
三、以fail fast为原则,需要fail fast情景抛出非受检异常(RuntimeException);其他情况抛出受检异常(Exception)
使用guava的Preconditions
(checkNotNull、checkArgument……)或jsr 303
(@NotNull、@NotBlank、@NotEmpty……)这种类似校验都抛出非受检异常(RuntimeException)。这些校验符合fail fast原则,你要不满足这些条件我就马上让你失败,啥也捞不到,并且也不告诉你要抛出什么类型的异常。剩下的就是业务逻辑的校验,抛出受检异常。
在目前的工作过程中,我总结出这三个不定法则,觉得这样做会少些麻烦、方便处理、少写代码,有了规则,让项目的后续开发以及维护都变得比较便利了。
如有不妥,欢迎拍砖。
参考文章:
如何优雅的设计 Java 异常
Java异常(二) 《Effective Java》中关于异常处理的几条建议