使用异常的优势

现在你知道了异常是什么,并且知道怎么使用它们,现在是时候讨论一下在你的程序中使用异常会有什么好处了。
 
优势1:隔离错误处理代码和常规代码
 
Exception提供了一种方法,把意外发生时的细节从程序主逻辑中隔离开来。在传统的编程中,错误的检测、报告和处理通常会导致像意大利面条那么混乱的代码。例如,请看下面的伪码,它把整个文件读入内存:
readFile {
    open the file;
    determine its size;
    allocate that much memory;
    read the file into memory;
    close the file;
}
第一眼看过去,这函数简单到不能再简单,但是它忽略了下列所有潜在的问题:
  • 如果文件不能打开怎么办?
  • 如果不能确定文件的大小怎么办?
  • 如果内存不够分配怎么办?
  • 如果文件读取失败怎么办?
  • 如果文件不能关闭怎么办?
 
为了处理这些问题,readFile函数必须有更多的代码来处理错误检测、报告和处理。这个函数可能会变成这样:
errorCodeType readFile {
    initialize errorCode = 0;
   
    open the file;
    if (theFileIsOpen) {
        determine the length of the file;
        if (gotTheFileLength) {
            allocate that much memory;
            if (gotEnoughMemory) {
                read the file into memory;
                if (readFailed) {
                    errorCode = -1;
                }
            } else {
                errorCode = -2;
            }
        } else {
            errorCode = -3;
        }
        close the file;
        if (theFileDidntClose && errorCode == 0) {
            errorCode = -4;
        } else {
            errorCode = errorCode and -4;
        }
    } else {
        errorCode = -5;
    }
    return errorCode;
}
有那么多的错误检测、报告和返回语句,让原本简单的5行代码完全迷失在乱哄哄的代码里面了。更糟糕的是,代码的逻辑流程也随着丢失了,因此很难说这段代码是否做了正确的事:当函数分配内存的时候失败了,文件能否确保被关闭?当你三个月之后再修改这段代码时,你就更难确定改完后代码还到底能不能用了。很多程序员解决的办法就是简单地忽略它——当他们的程序崩溃了报告一下错误就行。
 
Exception可以让你能在一个地方写好代码主流程,在另外一个处理异常情况。如果readFile函数改用Exception来替换传统的错误管理技术,看起来就像下面的代码:
readFile {
    try {
        open the file;
        determine its size;
        allocate that much memory;
        read the file into memory;
        close the file;
    } catch (fileOpenFailed) {
      doSomething;
    } catch (sizeDeterminationFailed) {
        doSomething;
    } catch (memoryAllocationFailed) {
        doSomething;
    } catch (readFailed) {
        doSomething;
    } catch (fileCloseFailed) {
        doSomething;
    }
}
要注意的是,使用Exception并不会让你在检测、报告和处理错误时更省力,但是可以让你把这些工作组织起来更高效。
 
优势2:在调用栈中向上传播错误
 
Exception的第二个优势就是,可以把错误报告给调用栈的上层方法。假如在主程序中,在一系列嵌套的调用方法中,readFile方法是第四个方法: method1调用method2,然后调用method3,最后调用readFile。
method1 {
    call method2;
}

method2 {
    call method3;
}

method3 {
    call readFile;
}

假设method1是唯一关心在readFile内发生了什么错误的方法。传统的错误通知技术强制method1和method2传播readFile返回的错误代码,直到错误代码最后传到method1——而method1是唯一需要返回码的方法。

method1 {
    errorCodeType error;
    error = call method2;
    if (error)
        doErrorProcessing;
    else
        proceed;}

errorCodeType method2 {
    errorCodeType error;
    error = call method3;
    if (error)
        return error;
    else
        proceed;}

errorCodeType method3 {
    errorCodeType error;
    error = call readFile;
    if (error)
        return error;
    else
        proceed;}

回忆一下,Java运行时系统通过逆向搜索,查找对某个异常感兴趣的任何方法。一个方法可以躲避任何抛给它的异常,从而让一个方法可以把异常抛到更远的调用栈中捕获。因此,只有关心错误的方法,才必须要去检测错误。

method1 {
    try {
        call method2;
    } catch (exception e) {
        doErrorProcessing;
    }
}

method2 throws exception {
    call method3;
}

method3 throws exception {
    call readFile;
}
然而,正如伪代码所示,中间人方法可以躲避掉后面必须要处理的异常。一个方法通过在throws从句中进行声明,可以抛掉任何检查异常。
 
优势3:归类和区分错误类型
 
因为程序抛出的所有异常都是对象,类是有层次结构的,所以对异常进行归类或分组是非常自然的结果。在Java平台中有一个例子,一组相关异常被定义在java.io包——IOException及其子类。IOException是最通用的,它代表了我们在执行I/O相关操作的时候发生的任何错误类型。它的继承者代表了更加细分的错误。例如,FileNotFoundException表示一个文件不能再磁盘中定位到。
 
一个方法可以写一个具体的处理器,能处理一个十分具体的异常。由于FileNotFoundException没有继承者,所以下面的这个异常处理器只能处理一种类型的异常:
catch (FileNotFoundException e) {
    ...
}
一个方法也可以用更通用的处理器捕获处理具体的异常。例如,为了捕获所有的I/O异常,不管具体的类型是什么,只要给异常处理器指定一个IOException参数就行。
catch (IOException e) {
    ...
}
这个处理器可以捕获所有的I/O异常,包括FileNotFoundException,EOFException等等。你可以通过查询传给异常处理器的参数,发现错误发生的细节。例如,用下面的代码打印堆栈跟踪信息:
catch (IOException e) {
    // Output goes to System.err.
    e.printStackTrace();
    // Send trace to stdout.
    e.printStackTrace(System.out);
}

你甚至可以构建一个可以处理所有异常的异常处理器:

// A (too) general exception handler
catch (Exception e) {
    ...
}
在Throwable类层级结构中,Exception类已经快接近顶点了。所以这个处理器将会捕获很多它不想捕获的异常。如果你想在整个程序中对所有异常都采取统一处理方式,你就可能会采取这种办法处理异常,例如,给用户打印错误信息并退出。
 
然而在大多数情况下,你希望异常处理器越具体越好。理由是在你决定最佳的恢复策略之前,你首先要知道错误的类型。事实上,如果不捕获具体的错误,这个处理器就必须要容纳任何可能性。太通用的异常处理器可能会让代码更容易出错,因为它们会捕获和处理程序员意料之外的异常,这样就超出处理器的能力范围了。
 
就像前面说过的,你可以创建一组异常,然后采用通用处理的风格。或者你可以使用具体的异常类型来区分不同的异常,然后用精确的风格处理异常。

 原文地址

转自:http://leaforbook.com/blog/jexception/translate/advantages.html

原文地址:https://www.cnblogs.com/hihtml5/p/6505801.html