Java应用架构中该如何设计异常？.docxVIP

Java应用架构中该如何设计特别？ 正如我们所晓得的，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，看了以上代码以后，你或许心中有一些想法，原来受检特别可以把握义务规律，对，没错，通过受检特别真的可以把握业务规律，但是切记不要这样使用，我们应当合理的抛出特别，由于程序本身才是流程，特别的作用仅仅是当你进行不下去的时候找到的一个借口而已，它并不能当成把握程序流程的入口或出口，假如这样使用的话，是在将特别的作用扩大化，这样将会导致代码简单程度的添加，耦合性会提高，代码可读性