java异常

运行时异常与一般异常有何异同

2009-08-25 22:55 11235人阅读 评论(5) 收藏 举报

exceptionjava虚拟机编译器jvm图形

Throwable 是所有 Java 程序中错误处理的父类 ，有两种资类： Error 和 Exception 。

   Error ：表示由 JVM 所侦测到的无法预期的错误，由于这是属于 JVM 层次的严重错误 ，导致 JVM 无法继续执行，因此，这是不可捕捉到的，无法采取任何恢复的操作，顶多只能显示错误信息。

Exception ：表示可恢复的例外，这是可捕捉到的。

Java 提供了两类主要的异常 :runtime exception 和 checked exception 。 checked 异常也就是我们经常遇到的 IO 异常，以及 SQL 异常都是这种异常。 对于这种异常， JAVA 编译器强制要求我们必需对出现的这些异常进行 catch 。所以，面对这种异常不管我们是否愿意，只能自己去写一大堆 catch 块去处理可能的异常。

    但是另外一种异常： runtime exception ，也称运行时异常，我们可以不处理。当出现这样的异常时，总是由虚拟机 接管。比如：我们从来没有人去处理过 NullPointerException 异常，它就是运行时异常，并且这种异常还是最常见的异常之一。

    出现运行时异常后，系统会把异常一直往上层抛，一直遇到处理代码。如果没有处理块，到最上层，如果是多线程就由 Thread.run()抛出 ，如果是单线程就被 main() 抛出 。抛出之后，如果是线程，这个线程也就退出了。如果是主程序抛出的异常，那么这整个程序也就退出了。运行时异常是 Exception 的子类，也有一般异常的特点，是可以被 Catch 块处理的。只不过往往我们不对他处理罢了。也就是说，你如果不对运行时异常进行处理，那么出现运行时异常之后，要么是线程中止，要么是主程序终止。

    如果不想终止，则必须扑捉所有的运行时异常，决不让这个处理线程退出。队列里面出现异常数据了，正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而影响下面对正常数据的处理。 在这个场景这样处理可能是一个比较好的应用，但并不代表在所有的场景你都应该如此。如果在其它场景，遇到了一些错误，如果退出程序比较好，这时你就可以不太理会运行时异常 ，或者是通过对异常的处理显式的控制程序退出。

异常处理的目标之一就是为了把程序从异常中恢复出来 。

 

转自：http://blog.csdn.net/yakihappy/archive/2009/03/11/3979883.aspx

 

 

异常表示程序运行过程中可能出现的非正常状态,运行时异常表示虚拟机的通常操作中可能遇到的异常,是一种常见运行错误.java编译器要求方法必须声明抛出可能发生的非运行时异常,但是并不要求必须声明抛出未被捕获的运行时异常.

   下面简单讲解一下有关JAVA异常的知识:

    1. 异常机制

    1.1

    异常机制是指当程序出现错误后,程序如何处理.具体来说,异常机制提供了程序退出的安全通道.当出现错误后,程序执行的流程发生改变,程序的控制权转移到异常处理器.

    1.2

    传统的处理异常的办法是,函数返回一个非凡的结果来表示出现异常(通常这个非凡结果是大家约定俗称的),调用该函数的程序负责检查并分析函数返回的结果. 这样做有如下的弊端:例如函数返回-1代表出现异常,但是假如函数确实要返回-1这个正确的值时就会出现混淆;可读性降低,将程序代码与处理异常的代码混 爹在一起;由调用函数的程序来分析错误,这就要求客户程序员对库函数有很深的了解.

    1.3 异常处理的流程

    1.3.1 碰到错误,方法立即结束,并不返回一个值;同时,抛出一个异常对象

    1.3.2 调用该方法的程序也不会继续执行下去,而是搜索一个可以处理该异常的异常处理器,并执行其中的代码

    2 异常的分类

    2.1 异常的分类

    2.1.1

    异常的继续结构:基类为Throwable,Error和Exception继续Throwable,RuntimeException和 IOException等继续Exception,具体的RuntimeException继续RuntimeException.

    2.1.2

    Error和RuntimeException及其子类成为未检查异常(unchecked),其它异常成为已检查异常(checked).

    2.2 每个类型的异常的特点

    2.2.1 Error体系

    Error类体系描述了Java运行系统中的内部错误以及资源耗尽的情形.应用程序不应该抛出这种类型的对象(一般是由虚拟机抛出).假如出现这种错误, 除了尽力使程序安全退出外,在其他方面是无能为力的.所以,在进行程序设计时,应该更关注Exception体系.

    2.2.2 Exception体系

    Exception体系包括RuntimeException体系和其他非RuntimeException的体系

    2.2.2.1 RuntimeException

    RuntimeException体系包括错误的类型转换、数组越界访问和试图访问空指针等等.处理RuntimeException的原则是:假如出现 RuntimeException,那么一定是程序员的错误.例如,可以通过检查数组下标和数组边界来避免数组越界访问异常.

    2.2.2.2 其他(IOException等等)

    这类异常一般是外部错误,例如试图从文件尾后读取数据等,这并不是程序本身的错误,而是在应用环境中出现的外部错误.

    2.3 与C++异常分类的不同

    2.3.1

    其实,Java中RuntimeException这个类名起的并不恰当,因为任何异常都是运行时出现的.(在编译时出现的错误并不是异常,换句话说,异常就是为了解决程序运行时出现的的错误).

    2.3.2

    C++中logic_error与Java中的RuntimeException是等价的,而runtime_error与Java中非RuntimeException类型的异常是等价的.

    3 异常的使用方法

    3.1 声明方法抛出异常

    3.1.1 语法:throws(略)

    3.1.2 为什么要声明方法抛出异常?

    方法是否抛出异常与方法返回值的类型一样重要.假设方法抛出异常确没有声明该方法将抛出异常,那么客户程序员可以调用这个方法而且不用编写处理异常的代码.那么,一旦出现异常,那么这个异常就没有合适的异常控制器来解决.

    3.1.3 为什么抛出的异常一定是已检查异常?

    RuntimeException与Error可以在任何代码中产生,它们不需要由程序员显示的抛出,一旦出现错误,那么相应的异常会被自动抛出.而已检 查异常是由程序员抛出的,这分为两种情况:客户程序员调用会抛出异常的库函数(库函数的异常由库程序员抛出);客户程序员自己使用throw语句抛出异 常.碰到Error,程序员一般是无能为力的;碰到RuntimeException,那么一定是程序存在逻辑错误,要对程序进行修改(相当于调试的一种 方法);只有已检查异常才是程序员所关心的,程序应该且仅应该抛出或处理已检查异常.

    3.1.4

    注重:覆盖父类某方法的子类方法不能抛出比父类方法更多的异常,所以,有时设计父类的方法时会声明抛出异常,但实际的实现方法的代码却并不抛出异常,这样做的目的就是为了方便子类方法覆盖父类方法时可以抛出异常.

    3.2 如何抛出异常

    3.2.1 语法:throw(略)

    3.2.2 抛出什么异常?

    对于一个异常对象,真正有用的信息时异常的对象类型,而异常对象本身毫无意义.比如一个异常对象的类型是ClassCastException,那么这个类名就是唯一有用的信息.所以,在选择抛出什么异常时,最要害的就是选择异常的类名能够明确说明异常情况的类.

    3.2.3

    异常对象通常有两种构造函数:一种是无参数的构造函数;另一种是带一个字符串的构造函数,这个字符串将作为这个异常对象除了类型名以外的额外说明.

    3.2.4

    创建自己的异常:当Java内置的异常都不能明确的说明异常情况的时候,需要创建自己的异常.需要注重的是,唯一有用的就是类型名这个信息,所以不要在异常类的设计上花费精力.

    3.3 捕捉异常

    假如一个异常没有被处理,那么,对于一个非图形界面的程序而言,该程序会被中止并输出异常信息;对于一个图形界面程序,也会输出异常的信息,但是程序并不中止,而是返回用户界面处理循环中.

    3.3.1 语法:try、catch和finally(略)

    控制器模块必须紧接在try块后面.若掷出一个异常,异常控制机制会搜寻参数与异常类型相符的第一个控制器随后它会进入那个catch

    从句,并认为异常已得到控制.一旦catch 从句结束对控制器的搜索也会停止.

    3.3.1.1 捕捉多个异常(注重语法与捕捉的顺序)(略)

    3.3.1.2 finally的用法与异常处理流程(略)

    3.3.2 异常处理做什么?

    对于Java来说,由于有了垃圾收集,所以异常处理并不需要回收内存.但是依然有一些资源需要程序员来收集,比如文件、网络连接和图片等资源.

    3.3.3 应该声明方法抛出异常还是在方法中捕捉异常?

    原则:捕捉并处理哪些知道如何处理的异常,而传递哪些不知道如何处理的异常

    3.3.4 再次抛出异常

    3.3.4.1 为什么要再次抛出异常?

    在本级中,只能处理一部分内容,有些处理需要在更高一级的环境中完成,所以应该再次抛出异常.这样可以使每级的异常处理器处理它能够处理的异常.

    3.3.4.2 异常处理流程

    对应与同一try块的catch块将被忽略,抛出的异常将进入更高的一级.

    4 关于异常的其他问题

    4.1 过度使用异常

    首先,使用异常很方便,所以程序员一般不再愿意编写处理错误的代码,而仅仅是简简单单的抛出一个异常.这样做是不对的,对于完全已知的错误,应该编写处理这种错误的代码,增加程序的鲁棒性.另外,异常机制的效率很差.

    4.2 将异常与普通错误区分开

    对于普通的完全一致的错误,应该编写处理这种错误的代码,增加程序的鲁棒性.只有外部的不能确定和预知的运行时错误才需要使用异常.

    4.3 异常对象中包含的信息

    一般情况下,异常对象唯一有用的信息就是类型信息.但使用异常带字符串的构造函数时,这个字符串还可以作为额外的信息.调用异常对象的 getMessage()、toString()或者printStackTrace()方法可以分别得到异常对象的额外信息、类名和调用堆栈的信息.并 且后一种包含的信息是前一种的超集.

 

转自：http://www.zhiweinet.com/jiaocheng/2008-09/1452.htm