引：今天去面试，和面试官的一些对话，面试官简称 面：
面：你们用的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捕获。
三、总结：
异常处理，值得拥有！
遇到问题，使用一项技术，多站在架构师的角度问自己一个为什么！