引:今天去面试,和面试官的一些对话,面试官简称 面:
面:你们用的Dubbo微服务,dubbo是可插拔的,这个模块突然被拔掉了,或者不在注册中心上了(反正就是调不到别的服务了)想过会出现问题,怎么处理吗?
我:没想过,编程的时候如果调不通别人的接口了,就觉得是不是服务器不稳定了,哪出问题了,开始联系组长。
面:调不通了肯定会报错,错误出现在页面或者日志里,是不是?
我:恩;
面:那有没有想过,我们没有try catch 这些异常,但是为什么这些异常还会出现在日志里?原理是什么?
我:(内心是有点崩溃的,想想把Java基础里关于异常处理的内容都看了一遍啊,还有没学到的)犹豫了一下,想不出来,说,JAVA虚拟机自动处理的。(面试的时候,还是要诚实的,不会的不要乱编,面试官大多懂的比我多,但是可以说自己的思路)
面:原理是什么?没有东西会自然而言的产生效果,为什么会出现在日志里呢?
我:想不到了。
面:Java异常有两种,一种是已知的异常,写一些调用文件的函数,没有写文件路径,这时候会提示去捕获这个异常,声明这个异常,另一种是运行时异常,运行时异常会捕获各种异常,毕竟写一个函数不能写几千几万行异常捕获,那就不用写代码了。这些处理不了的运行时异常在基本的类里捕捉了,再打印出来。
顿悟,这不就是前天学习的checked异常和Runtime异常嘛。
一、Java常见异常类之间的继承关系:
Error错误:与虚拟机有关的异常,比如:系统崩溃,虚拟机错误,动态链接失败,这些错误无法恢复,或者不可能捕捉。
Exception:分为RuntimeException和 checked异常
二、关于RuntimeException和itooRuntimeException
常见的异常:空指针,下标越界,参数校验,JVM已经对其进行序列化处理,自动catch住后,会抛出正常的异常信息。但是在ITOO项目中,可能因为要解决一下问题,引用了第三方技术:rabbitMQ,fastDFS等,catch的异常不属于JVM异常,没有经过JVM序列化,RuntimeException会对异常进行封装,导致客户端不能从异常中获取有效信息,抛出后,提示的信息可能不是问题本身,我们不知道问题出在哪了。所以,itoo中用itooRuntimeException对捕获的异常进行序列化处理,在controller中就可以看到我们想看到的内容了。再想想面试官的问题,就会想到,在调用别的服务调不通时出现的异常,就会被itooRuntimeException捕获。
三、总结:
异常处理,值得拥有!
遇到问题,使用一项技术,多站在架构师的角度问自己一个为什么!