[03] 为什么要使用异常机制

最新推荐文章于 2023-11-27 08:51:10 发布

weixin_30387663

最新推荐文章于 2023-11-27 08:51:10 发布

阅读量148

点赞数

文章标签： java

原文链接：http://www.cnblogs.com/deng-cc/p/7462539.html

版权

因为代码经验和见识等原因，说实话现在对于异常的使用，我也算是理解甚少。为什么用？什么时候用？即便是在查阅了部分资料以后，也只能在这里提炼出部分自己能够理解的，以供参考和讨论。

1、使用异常的好处

1.1 隔离常规代码和错误处理代码

实际上，我们希望程序不要出现问题，用户操作永远逻辑清晰而正确，一切都按照我们祈祷的那样运行，然而这是不可能的。必然会有错误必然会要我们去处理，但是错误的处理并不是我们代码的核心。

就像用户取钱的操作，我们核心的代码应该是账户金额变动和更新，而过程中可能出现的各种意外如余额不足，取钱超出额度等夹杂在我们的正常逻辑里，代码必然显得混乱，可读性差。而异常机制将这些意外情况剥离了出来。

我们用个简单的例子来说明：

//假如我们要实现将一个文件读入内存，实际上真正核心只需要下面5步  
readFile {
    open the file;
    determine its size;
    allocate that much memory;
    read the file into memory;
    close the file;
}

              
          
//假如我们要实现将一个文件读入内存，实际上真正核心只需要下面5步  
readFile {
    open the file;
    determine its size;
    allocate that much memory;
    read the file into memory;
    close the file;
}

//为了处理文件不能打开、不能确定文件大小、内存分配不足等可能出现的意外，我们可能最终写成如下
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;
}

              
          
//为了处理文件不能打开、不能确定文件大小、内存分配不足等可能出现的意外，我们可能最终写成如下
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;
}

如此我们得到的是混乱糟糕的代码，可读性极差，将来一旦出现需要维护的情况，更是苦不堪言。而当我们使用异常机制来处理时，清晰的处理逻辑和代码可读性不言而喻：

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;
    }
}

              
          
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;
    }
}

（笔者：如上例所有核心代码都用try包裹，确实代码清晰；而事实上倡导的是尽量减小try块，我个人在写一些涉及到IO的方法时，代码经常因为这个原则被try-catch分割得七零八落，基本上和使用if-else无差，所以个人认为try块对于代码的粒度控制，不必完全基于尽量最小的原则，毕竟同时try-catch的性能影响微乎其微）

1.2 延迟处理

throws关键字的使用，使得可能出现的错误不必在当前逻辑中立即处理，而是留待给它的调用者来处理。

因为很多时候，某些底层方法是不知道要如何去处理这些错误的，而只有业务层根据实际的业务逻辑和需求，才知道如何处理，比如业务层可能会将错误信息显示给用户，以起提示和引导操作。

实际上，也可以选择层层抛出的方式，即“ catch语句中处理异常后，再次throw抛出该异常 ”，继续抛出异常可使得调用方法能够再次获得并处理异常。比如程序员可以在底层方法中抓到异常后，打印错误日志以供开发者查看，同时再次抛出给上层调用者，以便业务层调用时使用，如显示错误信息给用户。

同时，受检类型的异常也起到了提醒的作用，告知调用者这个方法可能发生异常，那么你必须进行捕获并考虑处理。

1.3 异常的精确定位

com.test9.MyException: 文件没有找到--02
    at com.test9.Test.g(Test.java:31)
    at com.test9.Test.main(Test.java:38)
Caused by: com.test9.MyException: 文件没有找到--01
    at com.test9.Test.f(Test.java:22)
    at com.test9.Test.g(Test.java:28)
    ... 1 more
Caused by: java.io.FileNotFoundException: G:\myfile\struts.txt (系统找不到指定的路径。)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:106)
    at java.io.FileInputStream.<init>(FileInputStream.java:66)
    at java.io.FileReader.<init>(FileReader.java:41)
    at com.test9.Test.f(Test.java:17)
    ... 2 more

              
          
com.test9.MyException: 文件没有找到--02
    at com.test9.Test.g(Test.java:31)
    at com.test9.Test.main(Test.java:38)
Caused by: com.test9.MyException: 文件没有找到--01
    at com.test9.Test.f(Test.java:22)
    at com.test9.Test.g(Test.java:28)
    ... 1 more
Caused by: java.io.FileNotFoundException: G:\myfile\struts.txt (系统找不到指定的路径。)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:106)
    at java.io.FileInputStream.<init>(FileInputStream.java:66)
    at java.io.FileReader.<init>(FileReader.java:41)
    at com.test9.Test.f(Test.java:17)
    ... 2 more