导语

异常处理惩罚是措施开拓中必不行少操纵之一，昆山软件开发，但如何正确优雅的对异常举办处理惩罚确是一门学问，笔者按照本身的开拓履向来谈一谈我是如何对异常举办处理惩罚的。
由于本文只作一些履历之谈，不涉及到基本常识部门，假如读者对异常的观念还很恍惚，请先查察基本常识。

如何选择异常范例

异常的种别

正如我们所知道的，java中的异常的超类是java.lang.Throwable(后文省略为Throwable),它有两个较量重要的子类,java.lang.Exception(后文省略为Exception)和java.lang.Error(后文省略为Error)，个中Error由JVM虚拟机举办打点,如我们所熟知的OutOfMemoryError异常等，所以我们本文不存眷Error异常，那么我们细说一下Exception异常。
Exception异常有个较量重要的子类，叫做RuntimeException。我们将RuntimeException或其他担任自RuntimeException的子类称为非受检异常(unchecked Exception)，其他担任自Exception异常的子类称为受检异常(checked Exception)。本文重点来存眷一下受检异常和非受检异常这两种异常。

如何选择异常

从笔者的开拓履向来看，假如在一个应用中，需要开拓一个要领(如某个成果的service要领)，这个要领假如中间大概呈现异常，那么你需要思量这个异常呈现之后是否挪用者可以处理惩罚，而且你是否但愿挪用者举办处理惩罚，假如挪用者可以处理惩罚，而且你也但愿挪用者举办处理惩罚，那么就要抛出受检异常，提醒挪用者在利用你的要领时，思量到假如抛出异常时假如举办处理惩罚，相似的，假如在写某个要领时，你认为这是个偶尔异常，理论上说，你以为运行时大概会遇到什么问题，而这些问题也许不是一定产生的，也不需要挪用者显示的通过异常来判定业务流程操纵的，那么这时就可以利用一个RuntimeException这样的非受检异常.
好了，预计我上边说的这段话，你读了许多遍也依然以为艰涩了。
那么，请随着我的思路，在逐步了解一下。

什么时候才需要抛异常

首先我们需要相识一个问题，什么时候才需要抛异常？异常的设计是利便给开拓者利用的，但不是乱用的，笔者对付什么时候抛异常这个问题也问了许多伴侣，能给出精确谜底简直实不多。其实这个问题很简朴，假如你以为某些”问题”办理不了了，那么你就可以抛出异常了。好比，你在写一个service,个中在写到某段代码处,你发明大概会发生问题，那么就请抛出异常吧，相信我，你此时抛出异常将是一个最佳机缘。

应该抛出奈何的异常

相识完了什么时候才需要抛出异常后，我们再思考一个问题，真的当我们抛出异常时，我们应该选用奈何的异常呢？毕竟是受检异常还长短受检异常呢(RuntimeException)呢？我来举例说明一下这个问题，先从受检异常说起,好比说有这样一个业务逻辑，需要从某文件中读取某个数据，这个读取操纵大概是由于文件被删除等其他问题导致无法获取从而呈现读取错误，那么就要从redis或mysql数据库中再去获取此数据,参考如下代码，getKey(Integer)为进口措施.

public String getKey(Integer key){
    String  value;
    try {
        InputStream inputStream = getFiles("/file/nofile");
        //接下来从流中读取key的value指
        value = ...;
    } catch (Exception e) {
        //假如抛出异常将从mysql可能redis举办取之
        value = ...;
    }
}

public InputStream getFiles(String path) throws Exception {
    File file = new File(path);
    InputStream inputStream = null;
    try {
        inputStream = new BufferedInputStream(new FileInputStream(file));
    } catch (FileNotFoundException e) {
        throw new Exception("I/O读取错误",e.getCause());
    }
    return inputStream;
}

ok，看了以上代码今后，你也许心中有一些想法，本来受检异常可以节制义务逻辑，对，没错，通过受检异常真的可以节制业务逻辑，可是切记不要这样利用，我们应该公道的抛出异常，因为措施自己才是流程，异常的浸染仅仅是当你举办不下去的时候找到的一个捏词罢了，它并不能当成节制措施流程的进口或出口，假如这样利用的话，是在将异常的浸染扩大化，这样将会导致代码庞洪水平的增加，耦合性会提高，代码可读性低落等问题。那么就必然不要利用这样的异常吗？其实也不是，在真的有这样的需求的时候，我们可以这样利用，只是切记，不要把它真的当成节制流程的东西或手段。那么毕竟什么时候才要抛出这样的异常呢？要思量，假如挪用者挪用堕落伍，必然要让挪用者对此错误举办处理惩罚才可以，满意这样的要求时，我们才会思量利用受检异常。