Java异常处理机制及两种异常的区别

java异常处理机制主要依赖于try，catch，finally，throw，throws五个关键字。

 

　　try 关键字后紧跟一个花括号括起来的代码块，简称try块。同理：下面的也被称为相应的块。

 

　　它里面可置引发异常的代码。catch后对应异常类型和一个代码块，用于表明catch块用于处理这种类型的代码块。后还可以跟一个finally块，finally块用于回收在try块里打开的物理资源，异常机制会保证finally块总被执行。throws关键字主要在方法签名中使用，用于声明该方法可能抛出的异常，而throw则用于抛出一个实际的异常，throw可以单独作为语句使用，抛出一个具体的异常的对象

　　java异常处理可以让程序具有更好的容错性，程序更加健壮。当程序　出现意外情形时，系统会自动生成一个Exception对象来通知程序，从而实现将“业务功能实现代码”和“错误处理代码”分离，提供更好的可读性。

　　如果执行try块里的业务逻辑代码时出现异常，系统自动会生成一个异常对象，该异常对象被提交给java运行环境，这个过程被称为抛出（throw）异常。当java运行环境收到异常对象时，会寻找处理该异常对象的catch块，如果找到合适的catch块并把该异常交给它处理，该过程被称为捕获异常；如果java运行环境找不到捕获异常的catch块，则运行环境终止，程序也将退出。

　　使用finally回收物理资源

　　当程序在try块里打开了的一些物理资源（数据库连接，网络连接及磁盘文件），这些物理资源必须显示回收。

　　为了保证一定能够回收try块中打开的物理资源，异常处理机制提供了finally块，无论try块中的代码是否出现异常，也不管在哪个catch块中被执行，finally块总会被执行。异常处理结构语法中只有try块是必须的，一旦没有try块，则不能出现catch和finally块，如果存在try块，则catch块和finally块都是可选的。但二者至少要出现其一。也可以同时出现多个catch块。catch块必须位于try块后面，而finally必须位于catch块后面（如果存在的话）；

　　当java程序执行try块，catch块，时遇到了return语句或throw语句，这两个语句都会导致该方法的立即结束，但是系统并不会立即执行这两个语句，而是去寻找该异常处理流程中是否包含finally块，如果没有finally块程序立即执行return语句或throw语句，方法终止。反之，则系统会立即执行finally块——只有当finally块执行完后，系统才会再次跳回来执行try块，catch块里的return或throw语句，如果同时在　finally块中也存在return或throw语句，则finally块已经终止了方法，自然不存在系统再次跳转去执行try或catch块里的return或throw语句。

　　使用throws声明抛出异常的思路是：当前方法不知道应该如何处理这种异常，该异常应该由上一级调用者处理，如果main方法也不知道如何处理这种异常类型。也可以使用throws声明抛出异常，把该异常交给javaJVM处理。

　　JVM对异常的处理方法：打印异常跟踪栈信息，并终止程序运

 

runtime exception和checked exception

 

        Java提供了两类主要的异常:runtime exception和checked exception。所有的checked exception是从java.lang.Exception类衍生出来的，而runtime exception则是从java.lang.RuntimeException或java.lang.Error类衍生出来的。 

　　它们的不同之处表现在两方面:机制上和逻辑上。

一、机制上 
　　它们在机制上的不同表现在两点:1.如何定义方法;2. 如何处理抛出的异常。

　* Runtime exceptions:

　　在定义方法时不需要声明会抛出runtime exception;

　　在调用这个方法时不需要捕获这个runtime exception;

　　runtime exception是从java.lang.RuntimeException或java.lang.Error类衍生出来的。

　　* Checked exceptions:

　　定义方法时必须声明所有可能会抛出的checked exception;

　　在调用这个方法时，必须捕获它的checked exception，不然就得把它的exception传递下去;

　　checked exception是从java.lang.Exception类衍生出来的。

二、逻辑上 
　　从逻辑的角度来说，checked exceptions和runtime exception是有不同的使用目的的。checked exception用来指示一种调用方能够直接处理的异常情况。而runtime exception则用来指示一种调用方本身无法处理或恢复的程序错误。

　　checked exception迫使你捕获它并处理这种异常情况。以java.net.URL类的构建器(constructor)为例，它的每一个构建器都会抛出MalformedURLException。MalformedURLException就是一种checked exception。设想一下，你有一个简单的程序，用来提示用户输入一个URL，然后通过这个URL去下载一个网页。如果用户输入的URL有错误，构建器就会抛出一个exception。既然这个exception是checked exception，你的程序就可以捕获它并正确处理:比如说提示用户重新输入。

总而言之，在程序的运行过程中一个checked exception被抛出的时候，只有能够适当处理这个异常的调用方才应该用try/catch来捕获它。而对于runtime exception，则不应当在程序中捕获它。如果你要捕获它的话，你就会冒这样一个风险:程序代码的错误(bug)被掩盖在运行当中无法被察觉。因为在程序测试过程中，系统打印出来的调用堆栈路径(StackTrace)往往使你更快找到并修改代码中的错误。有些程序员建议捕获runtime exception并纪录在log中，我反对这样做。这样做的坏处是你必须通过浏览log来找出问题，而用来测试程序的测试系统(比如Unit Test)却无法直接捕获问题并报告出来。

            针对 RuntimeException 类型的异常， javac  是无法通过编译时的静态语法检测来判断到底哪些函数（或哪些区域的代码）可能抛出这类异常（这完全取决于运行时状态，或者说运行态所决定的）理解为non_checked可以？，也正因为如此， Java 异常处理模型中的“ must be caught or declared to be thrown ”规则也不适用于 RuntimeException （所以才有前面所提到过的奇怪编译现象，这也属于特殊规则吧）。但是，  Java 虚拟机却需要有效地捕获并处理此类异常。当然， RuntimeException 也可以被程序员显式地抛出，而且为了程序的可靠性，对一些可能出现“运行时异常（ RuntimeException ）”的代码区域，程序员最好能够及时地处理这些意外的异常，也即通过 catch(RuntimeExcetion) 或 catch(Exception) 来捕获它们。

     总结：

        所有异常的根类为java.lang.Throwable,Throwable下面又派生了两个子类：Error和Exception。error表示恢复不是不可能但很困难情况下的一种严重的问题。比如说内存溢出，不可能指望程序处理这样的情况，exception表示一种设计或实现问题，也就是说，它表示如果程序运行正常，从不会发生的情况。

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