Exception VS RuntimeException

这篇文章的由来说起来惭愧，今天在给新项目的网络框架添加一些公共的处理方法的时候，在解析JSON的BaseResult类里面，希望对某些CODE进行统一异常处理(网络框架是 Retrofit2+RXJava)：

public class BaseResultFunc<T> implements Func1<BaseResult<T>, T> {
    @Override
    public T call(BaseResult<T> tBaseResult) {
        if (tBaseResult.error_code != NetWork.RESULT_OK)
            throw new TipException("");
        return tBaseResult.result;
    }
}

一切看上去都很正常，结果在throw new TipException("")这一行出了问题，系统非要我 try/catch，然后看了下，原来我的 TipException 继承的是 Exception，那么问题就来了

---

JAVA中的异常概述：

在java的异常类体系中,Error和RuntimeException是非检查型异常，其他的都是检查型异常。

所有方法都可以在不声明throws的情况下抛出RuntimeException及其子类

不可以在不声明的情况下抛出非RuntimeException

简单的说，非RuntimeException要自己写catch块处理掉。

我们举个非常经典的列子 – Integer.parseInt：

 public static void main(String[] args) {
        String str="123";
        int temp=Integer.parseInt(str);
     }

源码：

public static int parseInt(String s) throws NumberFormatException {
    return parseInt(s,10);
    }

parseInt 这个方法中抛出了NumberFormatException异常，但是在上面的代码中我们没有找到try…catch来处理，这是为什么呢。按照我们异常处理的知识，如果一个方法通过throws抛出了异常，那么可以在抛出异常的方法中不适用try…catch，但是在调用这个方法的地方必须有try…catch来处理。
然后，我们追溯到NumberFormatException的父类会发现，它继承自RuntimeException，那么自然不需要catch。

---

最后，虽然RuntimeException是不需要 try/catch 的，但是在开发中最好是要做处理，毕竟一旦异常了，程序就停止运行了，而我使用也是在回调的函数中处理了。