【雨夜】业务中自定义异常用 Exception 还是 RuntimeException? 为什么？

矫情吗；* 2023-10-03 21:36 11阅读 0赞

今天和同事 聊了下异常 相关的事，整理在此

`目前公司中使用的 自定义异常是 extend RuntimeException`

## 目录 思维导图 ##

![format_png][]

## 继承异常 ##

### 我们在业务开发中 继承异常是extend RuntimeException 还是 Exception呢 ###

一想 这肯定是 RuntimeException 啊，但是这是为什么呢？ 选择 Exception 不行么？

### RuntimeException和Exception区别 ###

聊这个之前 我们需要确定我们的需求是什么

#### 需求 ####

需求是 **自定义一个 业务中使用的异常**

确定了需求 接下来我们就要分析

![format_png 1][]

到这里 知道 我们**业务开发 基本都是运行时异常 所以用 RuntimeException**

到这里有一个疑问，我们平时 IO操作的时候 动不动就爆红 让我们throws 或者 try catch，是哪个属性做到的？

首先看一段代码

![format_png 2][]

但是这个异常是因为createNewFile 方法 主动抛出的异常 和 是不是 RuntimeException 没关系啊

public boolean createNewFile() throws IOException {
        SecurityManager security = System.getSecurityManager();
        if (security != null) security.checkWrite(path);
        if (isInvalid()) {
            throw new IOException("Invalid file path");
        }
        return fs.createFileExclusively(path);
    }
    复制代码

是有关系的，非RuntimeException 都是需要throws 或者try catch 但是这个不是自动的，是开发人员写代码的时候 需要做的，代表这个异常是 **必须被检查的**

而其他需要注意的 引用 **程序设计语言原理** 书中 第434页的一部分

这块对于业务中使用哪个 先留一个疑问 往下看

![format_png 3][]

#### 怎么才算其他RuntimeException 代码上有什么区别？ ####

没有区别就是一个继承 RuntimeException，另一个继承 Exception，别的没有了

## 事务中拦截异常 ##

我们到这 知道了继承异常应该用RuntimeException，但是我们应该知道 **阿里规约手册** 中有这么一段

1、让检查异常也回滚：你就需要在整个方法前加上@Transactional(rollbackFor=Exception.class)

2、让非检查异常不回滚：  
需要加入@Transactional(notRollbackFor=RunTimeException.class)

3、不需要事务管理（or 日志丢失）  
需要加入@Transactional(propagation=Propagation.NOT\_SUPPORTED)

### 为什么这么设置？ ###

Exception类下面除了runtimeException还有SQLException和ioException

如果方法没有抛出runtimeException 而是抛出 **SQLException**和**ioException**那么事务是不会回滚的

那么这就结束了吗？在我们编码过程中，如果方法要抛出一些**可检查异常**时是需要throws进行显式指定异常类的

那么问题来了，我们都知道方法签名中默认是throws RuntimeException,已知SqlException不是RuntimeException的子类

#### 小总结 ####

@Transactional(notRollbackFor=RunTimeException.class) 是因为抛弃了 IO异常和 SQL异常等情况，所以 我们 应该用 Transactional(rollbackFor=Exception.class)

### 为什么 不是 rollbackFor = Throwable.class 呢 ###

不需要显式指定`rollbackFor = Throwable.class`，因为如果发生`错误`，spring将默认回滚事务。\*\*

**原本就是除了 非RuntimeException 别的已经在事务管理中了**

> 在其默认配置中，Spring Framework的事务基础结构代码仅标记事务对于运行时回滚，未经检查的异常;也就是说，抛出的异常是RuntimeException的实例或子类。 **（错误也会 - 默认情况下会导致回滚）** 。从事务方法抛出的已检查异常不会导致在默认配置中回滚。\*\*

或者查看`DefaultTransactionAttribute`

public boolean rollbackOn(Throwable ex) { 
            return (ex instanceof RuntimeException || ex instanceof Error); 
    }
    复制代码

具体位置 [docs.spring.io/spring-fram…][docs.spring.io_spring-fram]

总结下来事务方面应该使用 @Transactional(rollbackFor=Exception.class)

写到这 你肯定想问 你百度一篇文档 就告诉我们 默认Error就在事务管理中？ **你做过实验么？**

![format_png 4][]

### 小实验 ###

@Transactional(rollbackFor = Exception.class)
        public void a() {
            Version version = new Version();
            version.setVersionName("test0123120123");
            version.setProjectId(1L);
            versionService.save(version);
            try{
                int i = 1 /0;
            }catch (Exception e){
                //抛出Error 异常
                throw new OutOfMemoryError("test 内存溢出 error");
            }
        }
    复制代码

执行结果 保证了事务，数据库没有新增

到这里 你肯定有疑问

### 你对 rollbackFor 设置为 Exception，是不是原来的 事务拦截就失效了（Error 和 Runtime异常），到底是 覆盖之前的数据 还是 扩展原来的数据（Error 和 Runtime异常） ###

![format_png 5][]

这是因为 触发了 下面的判断，初步得到结论 是 **扩展**

public boolean rollbackOn(Throwable ex) { 
            return (ex instanceof RuntimeException || ex instanceof Error); 
    }
    复制代码

继续实验

if (winner == null) {
        //说明 rollbackFor 没有命中这个异常,执行默认的判断 (ex instanceof RuntimeException || ex instanceof Error)
        //如果是 Error 异常 走这个分支
        logger.trace("No relevant rollback rule found: applying default rules");
        return super.rollbackOn(ex);
    } else {
        //说明 rollbackFor 命中了 这个异常
        return !(winner instanceof NoRollbackRuleAttribute);
    }
    复制代码

到这 我们就要 往回分析 winner 是怎么赋值的呢？

### 额外的学习点 ###

#### 怎么判断异常 ####

RollbackRuleAttribute winner = null;
    int deepest = Integer.MAX_VALUE;
    if (this.rollbackRules != null) {
        Iterator var4 = this.rollbackRules.iterator();
    
        while(var4.hasNext()) {
            RollbackRuleAttribute rule = (RollbackRuleAttribute)var4.next();
            //获取这个异常的 int 等级 ，越小越优先
            int depth = rule.getDepth(ex);
            if (depth >= 0 && depth < deepest) {
                deepest = depth;
                winner = rule;
            }
        }
    }
    复制代码

#### List RollbackRuleAttribute rollbackRules 的值是怎么初始化的 ####

其实一句话 怎么从 @Transactional(rollbackFor=Exception.class) 变为 list对象的？ 走的是SpringTransactionAnnotationParser 类中的 parseTransactionAnnotation 方法

![format_png 6][]

#### 小总结 ####

一句话 对事务是否生效的判断 是 在 (ex instanceof RuntimeException || ex instanceof Error) 基础上，进行了 扩展的判断

## 其他中间件 对异常的应用场景 和 为什么？ ##

### 先看nacos ###

//检查 异常
    public class NacosException extends Exception {
    }
    复制代码

在使用的时候

![format_png 7][]

有throws 的 也有 try catch的

那么 是什么抛出Nacos 异常的呢？

private <T extends Response> T requestToServer(AbstractNamingRequest request, Class<T> responseClass)
            throws NacosException {
        try {
            xxx
        } catch (Exception e) {
            throw new NacosException(NacosException.SERVER_ERROR, "Request nacos server failed: ", e);
        }
        throw new NacosException(NacosException.SERVER_ERROR, "Server return invalid response");
    }
    复制代码

### rocketmq ###

先看一个 运行时异常

运行时异常
    public class AclException extends RuntimeException {
    }
    复制代码

使用

public static void verify(String netaddress, int index) {
        if (!AclUtils.isScope(netaddress, index)) {
            //运行的时候 发生异常
            throw new AclException(String.format("Netaddress examine scope Exception netaddress is %s", netaddress));
        }
    }
    复制代码

再看一个 检查异常

public class MQClientException extends Exception {
    }
    复制代码

throws MQClientException, RemotingException, MQBrokerException
    复制代码

使用

public TransactionSendResult sendMessageInTransaction(final Message msg,
        final LocalTransactionExecuter localTransactionExecuter, final Object arg)
        throws MQClientException {
        TransactionListener transactionListener = getCheckListener();
        if (null == localTransactionExecuter && null == transactionListener) {
            //如果为空 client 异常
            throw new MQClientException("tranExecutor is null", null);
        }
     }
    复制代码

## 总结 ##

中间件中大部分都是 client 连接失败，远程连接超时，server端异常 这种，属于检查时异常，所以应该 extend Exception

但是

1.  业务开发的时候 大部分都是 判断空，属于运行时异常 推荐 RunntimeException
2.  检查时异常 需要一直 throws，从代码整洁度上 推荐 RunntimeException

总结

1.  远程连接的使用 / 异常 使用检查时异常，**让另一端能感受到异常**
2.  业务中的代码使用 运行时异常

我还是**推荐业务使用 extends RuntimeException**，其余的就需要根据业务场景选择了

## 思考 ##

`ok 那你说 远程连接使用 检查时异常，那feign 属于远程rpc，他的异常就必须是 检查时异常么？为什么？`

[format_png]: https://img-blog.csdnimg.cn/img_convert/d73f9add9df8faca6150c64f7311ff3f.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/4a64e85e9c72734966e268af695fa49c.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/e7ff7ecc8144b9dfd2fc27b7354a34ce.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/06f0c1fa0d37b9215715e7e0c06f73a2.webp?x-oss-process=image/format,png
[docs.spring.io_spring-fram]: https://link.juejin.cn?target=https%3A%2F%2Fdocs.spring.io%2Fspring-framework%2Fdocs%2F3.2.6.RELEASE%2Fspring-framework-reference%2Fhtml%2Ftransaction.html%23transaction-declarative-rolling-back
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/da7baacebd4a507668bf393f63fb611e.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/c9a1aecd6cb997b56fa6afcbdb1c7c6e.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/8d8af8ecd464ef9268db7dd895b2e739.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/7bcf5727dc096fbf06b4629b8c1beddb.webp?x-oss-process=image/format,png