如何设计优雅的 Java 异常？.docx

第

如何设计优雅的Java异常？

什么时候才需要抛异常

首先我们需要了解一个问题，什么时候才需要抛异常？异常的设计是方便给开发者使用的，但不是乱用的，笔者对于什么时候抛异常这个问题也问了很多朋友，能给出准确答案的确实不多。其实这个问题很简单，如果你觉得某些问题解决不了了，那么你就可以抛出异常了。比如，你在写一个service,其中在写到某段代码处,你发现可能会产生问题，那么就请抛出异常吧，相信我，你此时抛出异常将是一个最佳时机。

应该抛出怎样的异常

了解完了什么时候才需要抛出异常后，我们再思考一个问题，真的当我们抛出异常时，我们应该选用怎样的异常呢？究竟是受检异常还是非受检异常呢(RuntimeException)呢？我来举例说明一下这个问题，先从受检异常说起,比如说有这样一个业务逻辑，需要从某文件中读取某个数据，这个读取操作可能是由于文件被删除等其他问题导致无法获取从而出现读取错误，那么就要从redis或MySQL数据库中再去获取此数据,参考如下代码，getKey(Integer)为入口程序.

publicStringgetKey(Integerkey){

Stringvalue;

try{

InputStreaminputStream=getFiles(/file/nofile

//接下来从流中读取key的value指

value=...;

}catch(Exceptione){

//如果抛出异常将从mysql或者redis进行取之

value=...;

}

}

publicInputStreamgetFiles(Stringpath)throwsException{

Filefile=newFile(path);

InputStreaminputStream=null;

try{

inputStream=newBufferedInputStream(newFileInputStream(file));

}catch(FileNotFoundExceptione){

thrownewException(I/O读取错误,e.getCause());

}

returninputStream;

}

ok，看了以上代码以后，你也许心中有一些想法，原来受检异常可以控制义务逻辑，对，没错，通过受检异常真的可以控制业务逻辑，但是切记不要这样使用，我们应该合理的抛出异常，因为程序本身才是流程，异常的作用仅仅是当你进行不下去的时候找到的一个借口而已，它并不能当成控制程序流程的入口或出口，如果这样使用的话，是在将异常的作用扩大化，这样将会导致代码复杂程度的增加，耦合性会提高，代码可读性降低等问题。那么就一定不要使用这样的异常吗？其实也不是，在真的有这样的需求的时候，我们可以这样使用，只是切记，不要把它真的当成控制流程的工具或手段。那么究竟什么时候才要抛出这样的异常呢？要考虑，如果调用者调用出错后，一定要让调用者对此错误进行处理才可以，满足这样的要求时，我们才会考虑使用受检异常。

接下来，我们来看一下非受检异常呢(RuntimeException)，对于RuntimeException这种异常，我们其实很多见，比如java.lang.NullPointerException／java.lang.IllegalArgumentException等，那么这种异常我们时候抛出呢？当我们在写某个方法的时候，可能会偶然遇到某个错误，我们认为这个问题时运行时可能为发生的，并且理论上讲，没有这个问题的话，程序将会正常执行的时候，它不强制要求调用者一定要捕获这个异常，此时抛出RuntimeException异常,举个例子，当传来一个路径的时候，需要返回一个路径对应的File对象:

publicvoidtest(){

myTest.getFiles(

}

publicFilegetFiles(Stringpath){

if(null==path||.equals(path)){

thrownewNullPointerException(路径不能为空!

}

Filefile=newFile(path);

returnfile;

}

上述例子表明，如果调用者调用getFiles(String)的时候如果path是空，那么就抛出空指