摘要：全局异常处理器处理异常时，会给前端返回错误信息，此时前端应该捕获并处理错误信息。
异常关系图
问题：
集群安装选择企业版导入，环境分离文件等信息填写错误，点击下一步，按钮一直处在加载中的状态。
此时根据控制台信息进行抓包，查看标头中接口的信息，发现是一个叫/host/fileExist/的接口有异常。
进入接口相关的代码中，查看是什么导致异常的出现。
发现其中一个叫fileExist()的函数在接口处抛出了异常，并未处理，猜想是异常未处理的原因，于是进行验证。
处理后：
状态码由500变成200，msg是"susses",data为false。
加载按钮也不是加载中了，报了文件找不到的错误。
就在以为问题解决了的时候，发现了后端有一个全局异常处理器。
所以，抛出的异常会被其捕获并处理掉，因此并非是后端的问题，应该是前端的错误信息没处理，导致一直在等待......
于是开始验证我的猜想：
第一步，先将异常还原，但将状态码修改为200。
状态码：
-
修改前
-
修改后
第二步，打包，运行datakit--导入安装---输入错误的环境分离变量，发现按钮并未在加载中，而是报出了文件找不到的错误。
于是，这说明200的状态码在前端可以被处理，但不是200的状态码产生的异常，并未被捕获并处理掉。
解决方法：
定位前端代码中，fileExist()函数传递的接口所在位置。
在调用fileExist()函数的类中，使得loading.value = false即可。
究其原因，是以上的操作改变了按钮的属性值，加载中的状态就会改变。
其他：
验证过程中，对于控制台中打印的响应为什么是msg和code，并且msg打印的是抛出异常的相关信息，也进行了定位。
总的来说，是全局异常处理器打印的。
如上代码，OpsException是一个自定义异常，它所携带的信息被全局异常处理器调用getMessage()方法调取了，并赋值给msg。
并且，因为data = null条件语句不满足，所以最后并未在控制台输出data，只输出了code和msg。
总结：
全局异常处理器处理异常时，会给前端返回错误信息，此时前端应该捕获并处理错误信息。
如果没有全局异常处理器，那么此时异常只能由JVM的默认异常处理器Thread.uncaughtExceptionHandler中的uncaughtException方法进行处理，处理之后程序会终止。
在前端处理错误信息时，将loading属性在接收处赋值为false，不然会一直等待异步处理，直到浏览器页面超时。
处理前：
处理后：
问号被称为可选链操作符，如果对象为null或者undefined，则返回undefined，不会抛出运行时错误。
