标签：Java 处理 抛出 程序 方法 ---- Checked 异常 讲义

 1.Checked异常和Runtime异常体系

        Java的异常被分为两大类:Checked异常和Runtime异常(运行时异常)。所有的RuntimeException类及其子类的实例被称为 Runtime异常;不是 RuntimeException类及其子类的异常实例则被称为Checked 异常。
        只有Java语言提供了Checked异常，其他语言都没有提供 Checked异常。Java认为Checked异常都是可以被处理(修复)的异常,所以Java程序必须显式处理Checked异常。如果程序没有处理Checked异常，该程序在编译时就会发生错误，无法通过编译。
        Checked异常体现了Java的设计哲学——没有完善错误处理的代码根本就不会被执行!对于Checked 异常的处理方式有如下两种。

• 当前方法明确知道如何处理该异常，程序应该使用try..catch 块来捕获该异常，然后在对应的catch块中修复该异常。例如,前面介绍的五子棋游戏中处理用户输入不合法的异常,程序在catch块中打印对用户的提示信息，重新开始下一次循环。
• 当前方法不知道如何处理这种异常，应该在定义该方法时声明抛出该异常。

        Runtime异常则更加灵活，Runtime异常无须显式声明抛出，如果程序需要捕获 Runtime异常，也可以使用try...catch块来实现。

  (1) 使用throws声明抛出异常

        使用throws声明抛出异常的思路是，当前方法不知道如何处理这种类型的异常，该异常应该由上一级调用者处理;如果main方法也不知道如何处理这种类型的异常,也可以使用throws声明抛出异常，该异常将交给JVM处理。JVM对异常的处理方法是，打印异常的跟踪栈信息，并中止程序运行，这就是前面程序在遇到异常后自动结束的原因。
        前面章节里有些程序已经用到了throws声明抛出，throws声明抛出只能在方法签名中使用，throws可以声明抛出多个异常类，多个异常类之间以逗号隔开。throws声明抛出的语法格式如下:

        上面throws声明抛出的语法格式仅跟在方法签名之后，如下例子程序使用了throws来声明抛出IOException异常，一旦使用throws语句声明抛出该异常，程序就无须使用try..catch块来捕获该异常了。

        上面程序声明不处理IOException异常，将该异常交给JVM处理，所以程序一旦遇到该异常，JVM就会打印该异常的跟踪栈信息，并结束程序。运行上面程序，会看到如图10.4所示的运行结果。

        如果某段代码中调用了一个带throws声明的方法，该方法声明抛出了Checked异常，则表明该方法希望它的调用者来处理该异常。也就是说，调用该方法时要么放在 try 块中显式捕获该异常，要么放在另一个带 throws声明抛出的方法中。如下例子程序示范了这种用法。

   (2) 方法重写时声明抛出异常的限制

        使用throws声明抛出异常时有一个限制，就是方法重写时“两小”中的一条规则:子类方法声明抛出的异常类型应该是父类方法声明抛出的异常类型的子类或相同,子类方法声明抛出的异常不允许比父类方法声明抛出的异常多。看如下程序。

        上面程序中 Sub子类中的 test()方法声明抛出 Exception，该Exception是其父类声明抛出异常IOException类的父类，这将导致程序无法通过编译。
        由此可见，使用Checked异常至少存在如下两大不便之处。

• 对于程序中的Checked异常, Java要求必须显式捕获并处理该异常,或者显式声明抛出该异常。这样就增加了编程复杂度。
• 如果在方法中显式声明抛出Checked 异常，将会导致方法签名与异常耦合，如果该方法是重写父类的方法，则该方法抛出的异常还会受到被重写方法所抛出异常的限制。

        在大部分时候推荐使用Runtime异常,而不使用Checked异常。尤其当程序需要自行抛出异常时(如何自行抛出异常请看下一节)，使用Runtime异常将更加简洁。
        当使用Runtime异常时，程序无须在方法中声明抛出Checked异常，一旦发生了自定义错误，程序只管抛出Runtime异常即可。
        如果程序需要在合适的地方捕获异常并对异常进行处理，则一样可以使用try ...catch块来捕获Runtime 异常。
        使用Runtime异常是比较省事的方式，使用这种方式既可以享受“正常代码和错误处理代码分离”,“保证程序具有较好的健壮性”的优势，又可以避免因为使用Checked异常带来的编程烦琐性。因此，C#、Ruby、Python等语言没有所谓的Checked异常，所有的异常都是Runtime异常。
        但Checked异常也有其优势——Checked异常能在编译时提醒程序员代码可能存在的问题，提醒程序员必须注意处理该异常，或者声明该异常由该方法调用者来处理，从而可以避免程序员因为粗心而忘记处理该异常的错误。

 2. 使用throw抛出异常

        当程序出现错误时，系统会自动抛出异常;除此之外，Java也允许程序自行抛出异常，自行抛出异常使用throw语句来完成（注意此处的throw没有后面的s，与前面声明抛出的throws是有区别的)。

  (1) 抛出异常

        异常是一种很“主观”的说法，以下雨为例，假设大家约好明天去爬山郊游，如果第二天下雨了，这种情况会打破既定计划,就属于一种异常;但对于正在期盼天降甘霖的农民而言,如果第二天下雨了，他们正好随雨追肥，这就完全正常。
        很多时候，系统是否要抛出异常，可能需要根据应用的业务需求来决定，如果程序中的数据、执行与既定的业务需求不符，这就是一种异常。由于与业务需求不符而产生的异常，必须由程序员来决定抛出，系统无法抛出这种异常。
        如果需要在程序中自行抛出异常，则应使用throw语句，throw语句可以单独使用，throw语句抛出的不是异常类，而是一个异常实例，而且每次只能抛出一个异常实例。throw语句的语法格式如下:

        上面程序中粗体字代码使用throw语句来自行抛出异常,程序认为当用户试图向一个已有棋子的坐标点下棋就是异常。当Java运行时接收到开发者自行抛出的异常时，同样会中止当前的执行流，跳到该异常对应的catch 块，由该catch 块来处理该异常。也就是说，不管是系统自动抛出的异常，还是程序员手动抛出的异常，Java运行时环境对异常的处理没有任何差别。
        如果throw语句抛出的异常是Checked异常，则该throw语句要么处于try块里,显式捕获该异常，要么放在一个带 throws声明抛出的方法中，即把该异常交给该方法的调用者处理;如果throw语句抛出的异常是Runtime异常，则该语句无须放在try块里，也无须放在带 throws声明抛出的方法中;程序既可以显式使用try..catch来捕获并处理该异常，也可以完全不理会该异常，把该异常交给该方法调用者处理。例如下面例子程序。

        通过上面程序也可以看出，自行抛出Runtime异常比自行抛出Checked异常的灵活性更好。同样,抛出 Checked异常则可以让编译器提醒程序员必须处理该异常。

  (2) 自定义异常类

        在通常情况下，程序很少会自行抛出系统异常，因为异常的类名通常也包含了该异常的有用信息。所以在选择抛出异常时，应该选择合适的异常类，从而可以明确地描述该异常情况。在这种情形下，应用程序常常需要抛出自定义异常。
        用户自定义异常都应该继承Exception基类，如果希望自定义Runtime 异常，则应该继承RuntimeException基类。定义异常类时通常需要提供两个构造器:一个是无参数的构造器;另一个是带一个字符串参数的构造器，这个字符串将作为该异常对象的描述信息（也就是异常对象的getMessage()方法的返回值)。
        下面例子程序创建了一个自定义异常类。

        上面程序创建了AuctionException异常类，并为该异常类提供了两个构造器。尤其是②号粗体字代码部分创建的带一个字符串参数的构造器，其执行休也非常简单，仅通过 super 来调用父类的构造器，正是这行super调用可以将此字符串参数传给异常对象的message属性，该message属性就是该异常对象的详细描述信息。
        如果需要自定义 Runtime异常，只需将AuctionException.java程序中的 Exception基类改为RuntimeException基类，其他地方无须修改。

  (3) catch和throw同时使用

        前面介绍的异常处理方式有如下两种。

• 在出现异常的方法内捕获并处理异常，该方法的调用者将不能再次捕获该异常。
• 该方法签名中声明抛出该异常，将该异常完全交给方法调用者处理。

        在实际应用中往往需要更复杂的处理方式——当一个异常出现时,单靠某个方法无法完全处理该异常，必须由几个方法协作才可完全处理该异常。也就是说，在异常出现的当前方法中，程序只对异常进行部分处理，还有些处理需要在该方法的调用者中才能完成，所以应该再次抛出异常，让该方法的调用者也能捕获到异常。
        为了实现这种通过多个方法协作处理同一个异常的情形,可以在catch块中结合throw语句来完成。如下例子程序示范了这种 catch和 throw同时使用的方法。

        上面程序中粗体字代码对应的catch 块捕获到异常后，系统打印了该异常的跟踪栈信息，接着抛出一个 AuctionException异常，通知该方法的调用者再次处理该AuctionException异常。所以程序中的main方法，也就是 bid()方法调用者还可以再次捕获AuctionException 异常，并将该异常的详细描述信息输出到标准错误输出。

   (4) Java 7增强的throw语句

        上面代码片段中的粗体字代码再次抛出了捕获到的异常，但这个ex对象的情况比较特殊:程序捕获该异常时,声明该异常的类型为Exception;但实际上 try 块中可能只调用了FileOutputStream构造器，这个构造器声明只是抛出了FileNotFoundException异常。
        在Java 7以前,Java编译器的处理"简单而粗暴”——由于在捕获该异常时声明ex的类型是Exception,因此Java编译器认为这段代码可能抛出 Exception异常，所以包含这段代码的方法通常需要声明抛出Exception异常。例如如下方法。

        从Java 7开始，Java编译器会执行更细致的检查，Java编译器会检查throw语句抛出异常的实际类型，这样编译器知道①号代码处实际上只可能抛出 FileNotFoundException异常，因此在方法签名中只要声明抛出 FileNotFoundException异常即可。即可以将代码改为如下形式（程序清单同上)。

  (5) 异常链

        对于真实的企业级应用而言，常常有严格的分层关系，层与层之间有非常清晰的划分，上层功能的实现严格依赖于下层的 API，也不会跨层访问。图10.5显示了这种具有分层结构应用的大致示意图。
        对于一个采用图10.5所示结构的应用，当业务逻辑层访问持久层出现SQLException异常时,程序不应该把底层的SQLException异常传到用户界面，有如下两个原因。

• 对于正常用户而言，他们不想看到底层SQLException异常，SQLException异常对他们使用该系统没有任何帮助。
• 对于恶意用户而言，将SQLException异常暴露出来不安全。

        把底层的原始异常直接传给用户是一种不负责任的表现。通常的做法是:程序先捕获原始异常，然后抛出一个新的业务异常，新的业务异常中包含了对用户的提示信息，这种处理方式被称为异常转译。假设程序需要实现工资计算的方法，则程序应该采用如下结构的代码来实现该方法。

        这种把原始异常信息隐藏起来，仅向上提供必要的异常提示信息的处理方式，可以保证底层异常不会扩散到表现层，可以避免向上暴露太多的实现细节，这完全符合面向对象的封装原则。
        这种把捕获一个异常然后接着抛出另一个异常﹐并把原始异常信息保存下来是一种典型的链式处理(23种设计模式之一:职责链模式)，也被称为“异常链”。
        在JDK 1.4以前，程序员必须自己编写代码来保持原始异常信息。从JDK 1.4以后，所有Throwable的子类在构造器中都可以接收一个cause对象作为参数。这个cause就用来表示原始异常，这样可以把原始异常传递给新的异常，使得即使在当前位置创建并抛出了新的异常，你也能通过这个异常链追踪到异常最初发生的位置。例如希望通过上面的SalException去追踪到最原始的异常信息，则可以将该方法改写为如下形式.

        上面程序中粗体字代码创建SalException对象时，传入了一个Exception对象，而不是传入了一个String对象，这就需要SalException类有相应的构造器。从JDK 1.4以后，Throwable基类已有了一个可以接收Exception参数的方法，所以可以采用如下代码来定义SalException类。

        创建了这个SalException 业务异常类后,就可以用它来封装原始异常,从而实现对异常的链式处理。

 3.Java的异常跟踪栈

        异常对象的printStackTrace()方法用于打印异常的跟踪栈信息，根据printStackTrace()方法的输出结果，开发者可以找到异常的源头，并跟踪到异常一路触发的过程。
        看下面用于测试 printStackTrace的例子程序。

        上面程序中main方法调用firstMethod, firstMethod调用secondMethod, secondMethod调用thirdMethod,thirdMethod直接抛出一个SelfException异常。运行上面程序，会看到如图10.6所示的结果。

        从图10.6中可以看出，异常从thirdMethod方法开始触发，传到secondMethod方法，再传到firstMethod方法,最后传到main方法，在main方法终止，这个过程就是Java的异常跟踪栈。
        在面向对象的编程中，大多数复杂操作都会被分解成一系列方法调用。这是因为:实现更好的可重用性，将每个可重用的代码单元定义成方法，将复杂任务逐渐分解为更易管理的小型子任务。由于一个大的业务功能需要由多个对象来共同实现，在最终编程模型中，很多对象将通过一系列方法调用来实现通信，执行任务。
        所以，面向对象的应用程序运行时，经常会发生一系列方法调用，从而形成“方法调用栈”，异常的传播则相反:只要异常没有被完全捕获(包括异常没有被捕获，或异常被处理后重新抛出了新异常)，异常从发生异常的方法逐渐向外传播，首先传给该方法的调用者，该方法调用者再次传给其调用者……直至最后传到main方法，如果main方法依然没有处理该异常，JVM会中止该程序，并打印异常的跟踪栈信息。
        很多初学者一看到如图10.6所示的异常提示信息，就会惊慌失措，其实图10.6所示的异常跟踪栈信息非常清晰它记录了应用程序中执行停止的各个点。
        第一行的信息详细显示了异常的类型和异常的详细消息。
        接下来跟踪栈记录程序中所有的异常发生点，各行显示被调用方法中执行的停止位置，并标明类、类中的方法名、与故障点对应的文件的行。一行行地往下看,跟踪栈总是最内部的被调用方法逐渐上传，直到最外部业务操作的起点,通常就是程序的入口main方法或Thread类的run方法(多线程的情形)。
        下面例子程序示范了多线程程序中发生异常的情形。

        运行上面程序，会看到如图10.7所示的运行结果。

        从图10.7中可以看出，程序在Thread 的 run方法中出现了ArithmeticException异常，这个异常的源头是ThreadExcetpionTest的secondMethod方法,位于 ThreadExcetpionTest.java 文件的27行。这个异常传播到Thread类的run方法就会结束（如果该异常没有得到处理,将会导致该线程中止运行).
        前面已经讲过，调用Exception的printStackTrace()方法就是打印该异常的跟踪栈信息，也就会看到如图10.6、图10.7所示的信息。当然，如果方法调用的层次很深，将会看到更加复杂的异常跟踪栈。

 4. 异常处理规则

        前面介绍了使用异常处理的优势、便捷之处，本节将进一步从程序性能优化、结构优化的角度给出异常处理的一般规则。成功的异常处理应该实现如下4个目标。

• 使程序代码混乱最小化。
• 捕获并保留诊断信息。
• 通知合适的人员。
• 采用合适的方式结束异常活动。

下面介绍达到这种效果的基本准则。

  (1) 不要过度使用异常

        不可否认，Java的异常机制确实方便，但滥用异常机制也会带来一些负面影响。过度使用异常主要有两个方面。

• 把异常和普通错误混淆在一起，不再编写任何错误处理代码，而是以简单地抛出异常来代替所有的错误处理。
• 使用异常处理来代替流程控制。

        熟悉了异常使用方法后，程序员可能不再愿意编写烦琐的错误处理代码，而是简单地抛出异常。实际上这样做是不对的，对于完全已知的错误，应该编写处理这种错误的代码，增加程序的健壮性;对于普通的错误，应该编写处理这种错误的代码，增加程序的健壮性。只有对外部的、不能确定和预知的运行时错误才使用异常。
        对比前面五子棋游戏中，处理用户输入坐标点已有棋子的两种方式。

        上面这种处理方式检测到用户试图下棋的坐标点已经有棋子了，立即打印一条提示语句，并重新开始下一次循环。这种处理方式简洁明了，逻辑清晰。程序的运行效率也很好——程序进入if块后，即结束了本次循环。

        上面的处理方式没有提供有效的错误处理代码,当程序检测到用户试图下棋的坐标点已经有棋子时，并没有提供相应的处理，而是简单地抛出了一个异常。这种处理方式虽然简单，但Java运行时接收到这个异常后，还需要进入相应的catch块来捕获该异常，所以运行效率要差一些。而且用户下棋重复这个错误完全是预料的，所以程序完全可以针对该错误提供相应的处理，而不是抛出异常。
        必须指出:异常处理机制的初衷是将不可预期异常的处理代码和正常的业务逻辑处理代码分离，因此绝不要使用异常处理来代替正常的业务逻辑判断。
        另外，异常机制的效率比正常的流程控制效率差，所以不要使用异常处理来代替正常的程序流程控制。例如，对于如下代码:

        运行上面程序确实可以实现遍历arr 数组元素的功能，但这种写法可读性较差，而且运行效率也不高。程序完全有能力避免产生ArrayIndexOutOfBoundsException异常，程序“故意”制造这种异常，然后使用catch块去捕获该异常，这是不应该的。将程序改为如下形式肯定要好得多:

  (2) 不要使用过于庞大的try块

        很多初学异常机制的读者喜欢在try 块里放置大量的代码，在一个try 块里放置大量的代码看上去“很简单”，但这种“简单”只是一种假象，只是在编写程序时看上去比较简单。但因为try块里的代码过于庞大，业务过于复杂，就会造成try块中出现异常的可能性大大增加，从而导致分析异常原因的难度也大大增加。
        而且当try块过于庞大时,就难免在try块后紧跟大量的catch块才可以针对不同的异常提供不同的处理逻辑。同一个try块后紧跟大量的catch块则需要分析它们之间的逻辑关系，反而增加了编程复杂度。
        正确的做法是，把大块的try块分割成多个可能出现异常的程序段落，并把它们放在单独的 try 块中，从而分别捕获并处理异常。

  (3) 避免使用Catch All语句

        所谓Catch All语句指的是一种异常捕获模块，它可以处理程序发生的所有可能异常。例如，如下代码片段:

        不可否认，每个程序员都曾经用过这种异常处理方式;但在编写关键程序时就应避免使用这种异常处理方式。这种处理方式有如下两点不足之处。

• 所有的异常都采用相同的处理方式，这将导致无法对不同的异常分情况处理，如果要分情况处理，则需要在catch 块中使用分支语句进行控制，这是得不偿失的做法。
• 这种捕获方式可能将程序中的错误、Runtime异常等可能导致程序终止的情况全部捕获到，从而“压制”了异常。如果出现了一些“关键”异常，那么此异常也会被“静悄悄”地忽略。

        实际上，Catch All语句不过是一种通过避免错误处理而加快编程进度的机制，应尽量避免在实际应用中使用这种语句。

  (4) 不要忽略捕获到的异常

        不要忽略异常!既然已捕获到异常，那 catch 块理应做些有用的事情——处理并修复这个错误。catch块整个为空，或者仅仅打印出错信息都是不妥的!
        catch 块为空就是假装不知道甚至瞒天过海，这是最可怕的事情─程序出了错误，所有的人都看不到任何异常，但整个应用可能已经彻底坏了。仅在catch 块里打印错误跟踪栈信息稍微好一点，但仅仅比空白多了几行异常信息。通常建议对异常采取适当措施，比如:

• 处理异常。对异常进行合适的修复，然后绕过异常发生的地方继续执行;或者用别的数据进行计算，以代替期望的方法返回值;或者提示用户重新操作……总之，对于Checked异常，程序应该尽量修复。
• 重新抛出新异常。把当前运行环境下能做的事情尽量做完，然后进行异常转译，把异常包装成当前层的异常，重新抛出给上层调用者。
• 在合适的层处理异常。如果当前层不清楚如何处理异常，就不要在当前层使用 catch语句来捕获该异常，直接使用throws声明抛出该异常，让上层调用者来负责处理该异常。

5.本章小结

        本章主要介绍了Java异常处理机制的相关知识，Java的异常处理主要依赖于try、catch、finally、throw和 throws 5个关键字，本章详细讲解了这5个关键字的用法。本章还介绍了Java异常类之间的继承关系，并介绍了Checked异常和Runtime异常之间的区别。本章也详细介绍了Java 7对异常处理的增强。本章还详细讲解了实际开发中最常用的异常链和异常转译。本章最后从优化程序的角度，给出了实际应用中处理异常的几条基本规则。

标签：Java,处理,抛出,程序,方法,----,Checked,异常,讲义
来源： https://blog.csdn.net/indeedes/article/details/121153814

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。