java异常（3）
原文出自：
Error（错误）表示系统级的错误和程序不必处理的异常，是java运行环境中的内部错误或者硬件问题。比如：内存资源不足等。对于这种错误，程序基本无能为力，除了退出运行外别无选择，它是由Java虚拟机抛出的。
Exception（违例）表示需要捕捉或者需要程序进行处理的异常，它处理的是因为程序设计的瑕疵而引起的问题或者在外的输入等引起的一般性问题，是程序必须处理的。
Exception又分为运行时异常，受检查异常。
运行时异常，表示无法让程序恢复的异常，导致的原因通常是因为执行了错误的操作，建议终止程序，因此，编译器不检查这些异常。
受检查异常，是表示程序可以处理的异常，也即表示程序可以修复（由程序自己接受异常并且做出处理）， 所以称之为受检查异常。
1. 异常机制&
异常机制是指当程序出现错误后，程序如何处理。具体来说，异常机制提供了程序退出的安全通道。当出现错误后，程序执行的流程发生改变，程序的控制权转移到异常处理器。
传统的处理异常的办法是，函数返回一个特殊的结果来表示出现异常（通常这个特殊结果是大家约定俗称的），调用该函数的程序负责检查并分析函数返回的结果。这样做有如下的弊端：例如函数返回-1代表出现异常，但是如果函数确实要返回-1这个正确的值时就会出现混淆；可读性降低，将程序代码与处理异常的代码混爹在一起；由调用函数的程序来分析错误，这就要求客户程序员对库函数有很深的了解。
异常处理的流程：
① 遇到错误，方法立即结束，并不返回一个值；同时，抛出一个异常对象 。
② 调用该方法的程序也不会继续执行下去，而是搜索一个可以处理该异常的异常处理器，并执行其中的代码 。
2 异常的分类&
异常的分类：
① 异常的继承结构：基类为Throwable，Error和Exception继承Throwable，RuntimeException和IOException等继承Exception，具体的RuntimeException继承RuntimeException。&
② Error和RuntimeException及其子类成为未检查异常（unchecked），其它异常成为已检查异常（checked）。
每个类型的异常的特点&
Error体系 ：
Error类体系描述了Java运行系统中的内部错误以及资源耗尽的情形。应用程序不应该抛出这种类型的对象（一般是由虚拟机抛出）。如果出现这种错误，除了尽力使程序安全退出外，在其他方面是无能为力的。所以，在进行程序设计时，应该更关注Exception体系。
Exception体系包括RuntimeException体系和其他非RuntimeException的体系：
① RuntimeException：RuntimeException体系包括错误的类型转换、数组越界访问和试图访问空指针等等。处理RuntimeException的原则是：如果出现RuntimeException，那么一定是程序员的错误。例如，可以通过检查数组下标和数组边界来避免数组越界访问异常。&
②其他非RuntimeException（IOException等等）：这类异常一般是外部错误，例如试图从文件尾后读取数据等，这并不是程序本身的错误，而是在应用环境中出现的外部错误。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：38428次
排名：千里之外
转载：23篇
(3)(1)(5)(4)(1)(1)(7)(12)(20)(2)(1)java RuntimeException -
- ITeye技术网站
博客分类：
总结了一下JAVA中常见的几种RuntimeException,大约有如下几种：
NullPointerException - 空指针引用异常
ClassCastException - 类型强制转换异常。
IllegalArgumentException - 传递非法参数异常。
ArithmeticException - 算术运算异常
ArrayStoreException - 向数组中存放与声明类型不兼容对象异常
IndexOutOfBoundsException - 下标越界异常
NegativeArraySizeException - 创建一个大小为负数的数组错误异常
NumberFormatException - 数字格式异常
SecurityException - 安全异常
UnsupportedOperationException - 不支持的操作异常
常见的RuntimeException- -
RuntimeException是开发中最容易遇到的，下面列举一下常见的RuntimeException：
1、NullPointerException：见的最多了，其实很简单，一般都是在null对象上调用方法了。
boolean eq=s.equals(""); // NullPointerException
这里你看的非常明白了，为什么一到程序中就晕呢？
public int getNumber(String str){
　　if(str.equals("A")) return 1;
　　 else if(str.equals("B")) return 2;
这个方法就有可能抛出NullPointerException,我建议你主动抛出异常，因为代码一多，你可能又晕了。
public int getNumber(String str){
　　if(str==null) throw new NullPointerException("参数不能为空");
//你是否觉得明白多了
　　if(str.equals("A")) return 1;
else if(str.equals("B")) return 2;
2、NumberFormatException：继承IllegalArgumentException，字符串转换为数字时出现。比如int i= Integer.parseInt("ab3");
3、ArrayIndexOutOfBoundsException:数组越界。比如 int[] a=new int[3]; int b=a[3];
4、StringIndexOutOfBoundsException：字符串越界。比如 String s="hello"; char c=s.chatAt(6);
5、ClassCastException:类型转换错误。比如 Object obj=new Object(); String s=(String)
6、UnsupportedOperationException:该操作不被支持。如果我们希望不支持这个方法，可以抛出这个异常。既然不支持还要这个干吗？有可能子类中不想支持父类中有的方法，可以直接抛出这个异常。
7、ArithmeticException：算术错误，典型的就是0作为除数的时候。
8、IllegalArgumentException：非法参数，在把字符串转换成数字的时候经常出现的一个异常，我们可以在自己的程序中好好利用这个异常。
我们可创建一个控制器，令其捕获所有类型的违例。具体的做法是捕获基础类违例类型Exception（也存在其他类型的基础违例，但Exception是适用于几乎所有编程活动的基础）。如下所示：　　catch(Exception e) {　　System.out.println("caught an exception");　　}　　这段代码能捕获任何违例，所以在实际使用时最好将其置于控制器列表的末尾，防止跟随在后面的任何特殊违例控制器失效。　　对于程序员常用的所有违例类来说，由于Exception类是它们的基础，所以我们不会获得关于违例太多的信息，但可调用来自它的基础类Throwable的方法：　　　　String getMessage()　　获得详细的消息。　　　　String toString()　　返回对Throwable的一段简要说明，其中包括详细的消息（如果有的话）。　　　　void printStackTrace()　　void printStackTrace(PrintStream)　　打印出Throwable和Throwable的调用堆栈路径。调用堆栈显示出将我们带到违例发生地点的方法调用的顺序。　　第一个版本会打印出标准错误，第二个则打印出我们的选择流程。若在Windows下工作，就不能重定向标准错误。因此，我们一般愿意使用第二个版本，并将结果送给System.out；这样一来，输出就可重定向到我们希望的任何路径。　　除此以外，我们还可从Throwable的基础类Object（所有对象的基础类型）获得另外一些方法。对于违例控制来说，其中一个可能有用的是getClass()，它的作用是返回一个对象，用它代表这个对象的类。我们可依次用getName()或toString()查询这个Class类的名字。亦可对Class对象进行一些复杂的操作，尽管那些操作在违例控制中是不必要的。本章稍后还会详细讲述Class对象。　　下面是一个特殊的例子，它展示了Exception方法的使用（若执行该程序遇到困难，请参考第3章3.1.2小节“赋值”）：　　//: ExceptionMethods.Java
　　// Demonstrating the Exception Methods
　　package c09;
　　public class ExceptionMethods {
　　　public static void main(String[] args) {
　　　　try {
　　　　　throw new Exception("Here's my Exception");
　　　　} catch(Exception e) {
　　　　　System.out.println("Caught Exception");
　　　　　System.out.println(
　　　　　　"e.getMessage(): " + e.getMessage());
　　　　　System.out.println(
　　　　　　"e.toString(): " + e.toString());
　　　　　System.out.println("e.printStackTrace():");
　　　　　e.printStackTrace();
　　} ///:~
　　该程序输出如下：　　　　Caught Exception　　e.getMessage(): Here's my Exception　　e.toString(): java.lang.Exception: Here's my Exception　　e.printStackTrace():　　java.lang.Exception: Here's my Exception　　　　　　at ExceptionMethods.main　　　　可以看到，该方法连续提供了大量信息——每类信息都是前一类信息的一个子集。
本章的第一个例子是：　　if(t == null)　　throw new NullPointerException();　　看起来似乎在传递进入一个方法的每个句柄中都必须检查null（因为不知道调用者是否已传递了一个有效的句柄），这无疑是相当可怕的。但幸运的是，我们根本不必这样做——它属于Java进行的标准运行期检查的一部分。若对一个空句柄发出了调用，Java会自动产生一个NullPointerException违例。所以上述代码在任何情况下都是多余的。　　这个类别里含有一系列违例类型。它们全部由Java自动生成，毋需我们亲自动手把它们包含到自己的违例规范里。最方便的是，通过将它们置入单独一个名为RuntimeException的基础类下面，它们全部组合到一起。这是一个很好的继承例子：它建立了一系列具有某种共通性的类型，都具有某些共通的特征与行为。此外，我们没必要专门写一个违例规范，指出一个方法可能会“掷”出一个RuntimeException，因为已经假定可能出现那种情况。由于它们用于指出编程中的错误，所以几乎永远不必专门捕获一个“运行期违例”——RuntimeException——它在默认情况下会自动得到处理。若必须检查RuntimeException，我们的代码就会变得相当繁复。在我们自己的包里，可选择“掷”出一部分RuntimeException。　　如果不捕获这些违例，又会出现什么情况呢？由于编译器并不强制违例规范捕获它们，所以假如不捕获的话，一个RuntimeException可能过滤掉我们到达main()方法的所有途径。为体会此时发生的事情，请试试下面这个例子：
　　//: NeverCaught.java
　　// Ignoring RuntimeExceptions
　　public class NeverCaught {
　　　static void f() {
　　　　throw new RuntimeException("From f()");
　　　static void g() {
　　　　f();
　　　public static void main(String[] args) {
　　　　g();
　　} ///:~
　　　　大家已经看到，一个RuntimeException（或者从它继承的任何东西）属于一种特殊情况，因为编译器不要求为这些类型指定违例规范。　　输出如下：　　　　java.lang.RuntimeException: From f()　　at NeverCaught.f(NeverCaught.java:9)　　at NeverCaught.g(NeverCaught.java:12)　　at NeverCaught.main(NeverCaught.java:15)　　　　所以答案就是：假若一个RuntimeException获得到达main()的所有途径，同时不被捕获，那么当程序退出时，会为那个违例调用printStackTrace()。　　注意也许能在自己的代码中仅忽略RuntimeException，因为编译器已正确实行了其他所有控制。因为RuntimeException在此时代表一个编程错误：　　(1) 一个我们不能捕获的错误（例如，由客户程序员接收传递给自己方法的一个空句柄）。　　(2) 作为一名程序员，一个应在自己的代码中检查的错误（如ArrayIndexOutOfBoundException，此时应注意数组的大小）。　　可以看出，最好的做法是在这种情况下违例，因为它们有助于程序的调试。　　另外一个有趣的地方是，我们不可将Java违例划分为单一用途的工具。的确，它们设计用于控制那些讨厌的运行期错误——由代码控制范围之外的其他力量产生。但是，它也特别有助于调试某些特殊类型的编程错误，那些是编译器侦测不到的。
覆盖一个方法时，只能产生已在方法的基础类版本中定义的违例。这是一个重要的限制，因为它意味着与基础类协同工作的代码也会自动应用于从基础类衍生的任何对象（当然，这属于基本的OOP概念），其中包括违例。　　下面这个例子演示了强加在违例身上的限制类型（在编译期）：　　　　//: StormyInning.Java
　　// Overridden methods may throw only the
　　// exceptions specified in their base-class
　　// versions, or exceptions derived from the
　　// base-class exceptions.
　　class BaseballException extends Exception {}
　　class Foul extends BaseballException {}
　　class Strike extends BaseballException {}
　　abstract class Inning {
　　　Inning() throws BaseballException {}
　　　void event () throws BaseballException {
　　　 // Doesn't actually have to throw anything
　　　abstract void atBat() throws Strike, F
　　　void walk() {} // Throws nothing
　　class StormException extends Exception {}
　　class RainedOut extends StormException {}
　　class PopFoul extends Foul {}
　　interface Storm {
　　　void event() throws RainedO
　　　void rainHard() throws RainedO
　　public class StormyInning extends Inning
　　　　implements Storm {
　　　// OK to add new exceptions for constrUCtors,
　　　// but you must deal with the base constructor
　　　// exceptions:
　　　StormyInning() throws RainedOut,
　　　　BaseballException {}
　　　StormyInning(String s) throws Foul,
　　　　BaseballException {}
　　　// Regular methods must conform to base class:
　　//! void walk() throws PopFoul {} //Compile error
　　　// Interface CANNOT add exceptions to existing
　　　// methods from the base class:
　　//! public void event() throws RainedOut {}
　　　// If the method doesn't already exist in the
　　　// base class, the exception is OK:
　　　public void rainHard() throws RainedOut {}
　　　// You can choose to not throw any exceptions,
　　　// even if base version does:
　　　public void event() {}
　　　// Overridden methods can throw
　　　// inherited exceptions:
　　　void atBat() throws PopFoul {}
　　　public static void main(String[] args) {
　　　　try {
　　　　　StormyInning si = new StormyInning();
　　　　　si.atBat();
　　　　} catch(PopFoul e) {
　　　　} catch(RainedOut e) {
　　　　} catch(BaseballException e) {}
　　　　// Strike not thrown in derived version.
　　　　try {
　　　　　// What happens if you upcast?
　　　　　Inning i = new StormyInning();
　　　　　i.atBat();
　　　　　// You must catch the exceptions from the
　　　　　// base-class version of the method:
　　　　} catch(Strike e) {
　　　　} catch(Foul e) {
　　　　} catch(RainedOut e) {
　　　　} catch(BaseballException e) {}
　　} ///:~
　　　　在Inning中，可以看到无论构建器还是event()方法都指出自己会“掷”出一个违例，但它们实际上没有那样做。这是合法的，因为它允许我们强迫用户捕获可能在覆盖过的event()版本里添加的任何违例。同样的道理也适用于abstract方法，就象在atBat()里展示的那样。　　“interface Storm”非常有趣，因为它包含了在Incoming中定义的一个方法——event()，以及不是在其中定义的一个方法。这两个方法都会“掷”出一个新的违例类型：RainedOut。当执行到“StormyInning extends”和“implements Storm”的时候，可以看到Storm中的event()方法不能改变Inning中的event()的违例接口。同样地，这种设计是十分合理的；否则的话，当我们操作基础类时，便根本无法知道自己捕获的是否正确的东西。当然，假如interface中定义的一个方法不在基础类里，比如rainHard()，它产生违例时就没什么问题。　　对违例的限制并不适用于构建器。在StormyInning中，我们可看到一个构建器能够“掷”出它希望的任何东西，无论基础类构建器“掷”出什么。然而，由于必须坚持按某种方式调用基础类构建器（在这里，会自动调用默认构建器），所以衍生类构建器必须在自己的违例规范中声明所有基础类构建器违例。　　StormyInning.walk()不会编译的原因是它“掷”出了一个违例，而Inning.walk()却不会“掷”出。若允许这种情况发生，就可让自己的代码调用Inning.walk()，而且它不必控制任何违例。但在以后替换从Inning衍生的一个类的对象时，违例就会“掷”出，造成代码执行的中断。通过强迫衍生类方法遵守基础类方法的违例规范，对象的替换可保持连贯性。　　覆盖过的event()方法向我们显示出一个方法的衍生类版本可以不产生任何违例——即便基础类版本要产生违例。同样地，这样做是必要的，因为它不会中断那些已假定基础类版本会产生违例的代码。差不多的道理亦适用于atBat()，它会“掷”出PopFoul——从Foul衍生出来的一个违例，而Foul违例是由atBat()的基础类版本产生的。这样一来，假如有人在自己的代码里操作Inning，同时调用了atBat()，就必须捕获Foul违例。由于PopFoul是从Foul衍生的，所以违例控制器（模块）也会捕获PopFoul。　　最后一个有趣的地方在main()内部。在这个地方，假如我们明确操作一个StormyInning对象，编译器就会强迫我们只捕获特定于那个类的违例。但假如我们上溯造型到基础类型，编译器就会强迫我们捕获针对基础类的违例。通过所有这些限制，违例控制代码的“健壮”程度获得了大幅度改善（注释③）。　　　　③：ANSI/ISO C++施加了类似的限制，要求衍生方法违例与基础类方法掷出的违例相同，或者从后者衍生。在这种情况下，C++实际上能够在编译期间检查违例规范。　　　　我们必须认识到这一点：尽管违例规范是由编译器在继承期间强行遵守的，但违例规范并不属于方法类型的一部分，后者仅包括了方法名以及自变量类型。因此，我们不可在违例规范的基础上覆盖方法。除此以外，尽管违例规范存在于一个方法的基础类版本中，但并不表示它必须在方法的衍生类版本中存在。这与方法的“继承”颇有不同（进行继承时，基础类中的方法也必须在衍生类中存在）。换言之，用于一个特定方法的“违例规范接口”可能在继承和覆盖时变得更“窄”，但它不会变得更“宽”——这与继承时的类接口规则是正好相反的。
RuntimeException可以由系统自动抛出，可以不进行try...catch
但如果有try,则必须有finally,可以没有catch
浏览 11165
浏览: 287419 次
来自: 杭州
下说法有误！如果两个对象的hashCode值相同，我们应该认为 ...
11 1111 ...
Cloudera Hadoop5&Hadoop高阶管理 ...
感谢楼主~~~~长知识了
非常感谢楼主的分享，解决了我的问题java（32）
今天看了一篇博客，java异常的，我觉得写得很通俗易懂 ，在这里记录一下。
先说说error，error一般是jvm抛出，内存资源耗尽或者一些内部问题，这个不应该出现在应用程序中，一般不去管它，而应该把精力放在Exception上。
& & & & &Exception继承体系，基类为Throwable，error和Exception继承于Throwable，runtimeException和ioException继承与Exception，具体的runtimeException继承于runtimeException。
& & & & &RuntimeException：RuntimeException体系包括错误的类型转换、数组越界访问和试图访问空指针等等。处理RuntimeException的原则是：如果出现RuntimeException，那么一定是程序员的错误。例如，可以通过检查数组下标和数组边界来避免数组越界访问异常。&
& & & &其他非RuntimeException（IOException等等）：这类异常一般是外部错误，例如试图从文件尾后读取数据等，这并不是程序本身的错误，而是在应用环境中出现的外部错误。
& & & & 声明：throwsthrows在函数的括号之后用，将需要抛出的异常进行声明，一个方法是否抛出异常和函数的返回值一样重要，如果不声明异常，而且内部没有自己编写的异常处理，那么方法就不知道该用什么异常控制器来处理。
throw用来抛出指定异常。
& & & & 抛出什么异常？对于一个异常对象，真正有用的信息时异常的对象类型，而异常对象本身毫无意义。比如一个异常对象的类型是ClassCastException，那么这个类名就是唯一有用的信息。所以，在选择抛出什么异常时，最关键的就是选择异常的类名能够明确说明异常情况的类。
&异常对象通常有两种构造函数：一种是无参数的构造函数；另一种是带一个字符串的构造函数，这个字符串将作为这个异常对象除了类型名以外的额外说明。&
&创建自己的异常：当Java内置的异常都不能明确的说明异常情况的时候，需要创建自己的异常。需要注意的是，唯一有用的就是类型名这个信息。
捕获异常，try，catch，finally，不管异常处理结果怎么样，都会进入到finally。
① 过度使用异常 ：首先，使用异常很方便，所以程序员一般不再愿意编写处理错误的代码，而仅仅是简简单单的抛出一个异常。这样做是不对的，对于完全已知的错误，应该编写处理这种错误的代码，增加程序的鲁棒性。另外，异常机制的效率很差。&
② 将异常与普通错误区分开：对于普通的完全一致的错误，应该编写处理这种错误的代码，增加程序的鲁棒性。只有外部的不能确定和预知的运行时错误才需要使用异常。&
③ 异常对象中包含的信息 ：一般情况下，异常对象唯一有用的信息就是类型信息。但使用异常带字符串的构造函数时，这个字符串还可以作为额外的信息。调用异常对象的getMessage()、toString()或者printStackTrace()方法可以分别得到异常对象的额外信息、类名和调用堆栈的信息。并且后一种包含的信息是前一种的超集。
& & & & &总之，异常经历了一个抛出捕获处理结束的过程。
最后，再引用thinking injava中的异常使用指南来结束，
1.在恰当的级别处理问题（在你知道如何处理的时候才去捕获）
2.解决并重新调用
产生异常的方法。
3.进行少许修补，然后绕过异常发生的地方继续执行。
4.用别的数据进行计算，以替代方法返回的期望值。
5,6。把当前运行环境下能做的事情尽量做完，然后把相同的（不同的）的异常重抛（抛）到更高的地方
7.终止程序。
9.进行简化。
10.让类库和程序更安全。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：32797次
排名：千里之外
原创：37篇
转载：24篇
(1)(2)(1)(2)(3)(1)(1)(1)(4)(2)(3)(1)(1)(16)(12)(4)(4)(1)(1)1. 异常机制 &&&&& 异常机制是指当程序出现错误后，程序如何处理。具体来说，异常机制提供了程序退出的安全通道。当出现错误后，程序执行的流程发生改变，程序的控制权转移到异常处理器。&异常处理的流程：① 遇到错误，方法不能够返回预期结果；同时，抛出一个异常对象 。② 调用该方法的程序也不会继续执行下去，而是搜索一个可以处理该异常的异常处理器，并执行其中的代码 。2 异常的分类 异常的分类：① 异常的继承结构：基类为Throwable，Error和Exception继承Throwable，RuntimeException和IOException等继承Exception，具体的RuntimeException继承RuntimeException。 ② Error和RuntimeException及其子类成为未检查异常（unchecked），其它异常成为已检查异常（checked）。每个类型的异常的特点 Error体系 ：&&&&& Error类体系描述了Java运行系统中的内部错误以及资源耗尽的情形。应用程序不应该抛出这种类型的对象（一般是由虚拟机抛出）。如果出现这种错误，除了尽力使程序安全退出外，在其他方面是无能为力的。所以，在进行程序设计时，应该更关注Exception体系。
Exception体系包括RuntimeException体系和其他非RuntimeException的体系：① RuntimeException：RuntimeException体系包括错误的类型转换、数组越界访问和试图访问空指针等等。处理RuntimeException的原则是：如果出现RuntimeException，那么一定是程序员的错误。例如，可以通过检查数组下标和数组边界来避免数组越界访问异常。 ②其他非RuntimeException（IOException等等）：这类异常一般是外部错误，例如试图从文件尾后读取数据等，这并不是程序本身的错误，而是在应用环境中出现的外部错误。 与C++异常分类的不同 ：① Java中RuntimeException这个类名起的并不恰当，因为任何异常都是运行时出现的。（在编译时出现的错误并不是异常，换句话说，异常就是为了解决程序运行时出现的的错误）。 ② C++中logic_error与Java中的RuntimeException是等价的，而runtime_error与Java中非RuntimeException类型的异常是等价的。3 异常的使用方法 声明方法抛出异常 ① 语法：throws② 为什么要声明方法抛出异常？ &&&&& 方法是否抛出异常与方法返回值的类型一样重要。假设方法抛出异常确没有声明该方法将抛出异常，那么客户程序员调用这个方法而不编写处理异常的代码。那么，一旦出现异常，那么这个异常就没有合适的异常控制器来解决。 ③ 为什么抛出的异常一定是已检查异常？ &&&&& RuntimeException与Error可以在任何代码中产生，它们不需要由程序员显示的抛出，一旦出现错误，那么相应的异常会被自动抛出。而已检查异常是由程序员抛出的，这分为两种情况：客户程序员调用会抛出异常的库函数（库函数的异常由库程序员抛出）；客户程序员自己使用throw语句抛出异常。遇到Error，程序员一般是无能为力的；遇到RuntimeException，那么一定是程序存在逻辑错误，要对程序进行修改（相当于调试的一种方法）；只有已检查异常才是程序员所关心的，程序应该且仅应该抛出或处理已检查异常。 &&&&& 注意：覆盖父类某方法的子类方法不能抛出比父类方法更多的异常，所以，有时设计父类的方法时会声明抛出异常，但实际的实现方法的代码却并不抛出异常，这样做的目的就是为了方便子类方法覆盖父类方法时可以抛出异常，典型应用如抽象类。
如何抛出异常& ① 抛出什么异常？对于一个异常对象，真正有用的信息是异常的对象类型，而异常对象本身毫无意义。比如一个异常对象的类型是ClassCastException，那么这个类名就是唯一有用的信息。所以，在选择抛出什么异常时，最关键的就是选择异常的类名能够明确说明异常情况的类，见名知意。 ② 异常对象通常有两种构造函数：一种是无参数的构造函数；另一种是带一个字符串的构造函数，这个字符串将作为这个异常对象除了类型名以外的额外说明。 ③ 创建自己的异常：当Java内置的异常都不能明确的说明异常情况的时候，需要创建自己的异常。需要注意的是，唯一有用的就是类型名这个信息，所以不要在异常类的设计上花费精力。
捕获异常 &&&&& 如果一个异常没有被处理，那么，对于一个非图形界面的程序而言，该程序会被中止并输出异常信息；对于一个图形界面程序，也会输出异常的信息，但是程序并不中止，而是返回用错误页面。&&&&& 语法：try、catch和finally，控制器模块必须紧接在try块后面。若抛出一个异常，异常控制机制会搜寻参数与异常类型相符的第一个控制器随后它会进入那个catch 从句，并认为异常已得到控制。一旦catch 从句结束对控制器的搜索也会停止。 &&&&& 捕获多个异常（注意语法与捕获的顺序）&&&&&& finally的用法与异常处理流程&&&&&& 异常处理做什么？对于Java来说，由于有了垃圾收集，所以异常处理并不需要回收内存。但是依然有一些资源需要程序员来收集，比如文件、网络连接和图片等资源。 &&&&& 应该声明方法抛出异常还是在方法中捕获异常？原则：捕捉并处理那些知道如何处理的异常，而传递那些不知道如何处理的异常。对于那些不知道该如何处理的异常可以⑴向上抛出⑵用RuntimeException包装，直接忽略异常，让它自己沿着调用栈向上"冒泡"，同时结合getCause()捕获并处理特定异常再次抛出异常 ①为什么要再次抛出异常？在本级中，只能处理一部分内容，有些处理需要在更高一级的环境中完成，所以应该再次抛出异常。这样可以使每级的异常处理器处理它能够处理的异常。 ②异常处理流程 ：对应与同一try块的catch块将被忽略，抛出的异常将进入更高的一级。③可以使用fillInStackTrace()方法增加重新抛出点信息。4 关于异常的其他问题 ① 过度使用异常：首先，使用异常很方便，所以程序员一般不再愿意编写处理错误的代码，而仅仅是简简单单的抛出一个异常。这样做是不对的，对于完全已知的错误，应该编写处理这种错误的代码，增加程序的健壮性。另外，异常机制的效率很差。 ② 将异常与普通错误区分开：对于普通的完全一致的错误，应该编写处理这种错误的代码，增加程序的健壮性。只有外部的不能确定和预知的运行时错误才需要使用异常。 ③ 异常对象中包含的信息：一般情况下，异常对象唯一有用的信息就是类型信息。但使用异常带字符串的构造函数时，这个字符串还可以作为额外的信息。调用异常对象的getMessage()、toString()或者printStackTrace()方法可以分别得到异常对象的额外信息、类名和调用堆栈的信息。并且后一种包含的信息是前一种的超集。
阅读(...) 评论()