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()方法可以分别得到异常对象的额外信息、类名和调用堆栈的信息。并且后一种包含的信息是前一种的超集。

常用异常：

　　UnsupportedOperationException不支持的操作

　　IllegalArgumentException非法参数

　　IndexOutOfBoundsException索引出界

　　IllegalStateException非法状态
异常跟普通的警告等有一定的区别。当应用程序发生异常时，会中断正在执行的程序的正常指令流。也就是说，发生异常后面的代码将得不到正确的执行。甚至还会触发数据库的回退操作。

    在Java开发平台中，异常包括预定义异常与自定义异常。这两种异常的类型互为补充。作为一个合格的程序开发人员，要善于在应用程序中使用异常。这可以提高应用程序的交互性。同时，也是保证应用程序正常运行的前提。故异常的处理对于开发一个优秀的应用程序来说非常的重要。为此笔者认为程序开发人员应该对Java应用程序的常见异常有一个深入的了解。只有在了解这些常见异常的情况下，才能够做好自定义异常的处理。

    一、常见异常的类型与原因。

    对于Java应用程序的常见异常，笔者认为程序开发人员要从两个方面去了解。一是要知道有哪些常见的Java应用程序异常，二是需要知道哪些原因可能会造成这个异常。这不仅需要程序管理人员在日常工作中要注意积累，在必要的情况下还需要去从其它渠道收集资料。笔者对此就进行一个分析，希望能够对各位程序开发人员有一定的帮助。

    1、 SQLException：操作数据库异常类。

    现在的Java应用程序大部分都是依赖于数据库运行的。当Java应用程序与数据库进行沟通时如果产生了错误，就会触发这个类。同时会将数据库的错误信息通过这个类显示给用户。也就是说，这个操作数据库异常类是数据库与用户之间异常信息传递的桥梁。如现在用户往系统中插入数据，而在数据库中规定某个字段必须唯一。当用户插入数据的时候，如果这个字段的值跟现有的纪录重复了，违反了数据库的唯一性约束，此时数据库就会跑出一个异常信息。这个信息一般用户可能看不到，因为其发生在数据库层面的。此时这个操作数据库异常类就会捕捉到数据库的这个异常信息，并将这个异常信息传递到前台。如此的话，前台用户就可以根据这个异常信息来分析发生错误的原因。这就是这个操作数据库异常类的主要用途。在Java应用程序中，所有数据库操作发生异常时，都会触发这一个类。所有此时Java应用程序本身的提示信息往往过于笼统，只是说与数据库交互出现错误，没有多大的参考价值。此时反而是数据库的提示信息更加有使用价值。

    2、 ClassCastException：数据类型转换异常。

    在Java应用程序中，有时候需要对数据类型进行转换。这个转换包括显示的转换与隐式的转换。不过无论怎么转换，都必须要符合一个前提的条件，即数据类型的兼容性。如果在数据转换的过程中，违反了这个原则，那么就会触发数据类型转换异常。如现在在应用程序中，开发人员需要将一个字符型的日期数据转换为数据库所能够接受的日期型数据，此时只需要在前台应用程序中进行控制，一般不会有问题。但是，如果前台应用程序缺乏相关的控制，如用户在输入日期的时候只输入月、日信息，而没有年份的信息。此时应用程序在进行数据类型转换的时候，就会出现异常。根据笔者的经验，数据类型转换异常在应用程序开发中使一个出现的比较多的异常，也是一个比较低级的异常。因为大部分情况下，都可以在应用程序窗口中对数据类型进行一些强制的控制。即在数据类型进行转换之前，就保证数据类型的兼容性。如此的话，就不容易造成数据类型的转换异常。如在只允许数值类型的字段中，可以设置不允许用户输入数值以外的字符。虽然说有了异常处理机制，可以保证应用程序不会被错误的运行。但是在实际开发中，还是要尽可能多的预见错误发生的原因，尽量避免异常的发生。

    3、 NumberFormatException：字符串转换为数字类型时抛出的异常。

    在数据类型转换过程中，如果是字符型转换为数字型过程中出现的问题，对于这个异常在Java程序中采用了一个独立的异常，即NumberFormatException.如现在讲字符型的数据“123456”转换为数值型数据时，是允许的。但是如果字符型数据中包含了非数字型的字符，如123#56，此时转换为数值型时就会出现异常。系统就会捕捉到这个异常，并进行处理。

Java应用程序中常见的异常类还有很多。如未找到相应类异常、不允许访问某些类异常、文件已经结束异常、文件未找到异常、字段未找到异常等等。一般系统开发人员都可以根据这个异常名来判断当前异常的类型。虽然不错，但是好记性不如烂笔头。程序开发人员在必要的时候（特别是存在自定义异常的时候），最后手头有一份异常明细表。如此的话，无论是应用程序在调试过程中发现问题，还是运行过程中接到用户的投诉，都可以及时的根据异常名字来找到异常发生的原因。从而可以在最短时间内解决异常，恢复应用程序的正常运行。这个措施笔者用了很多年，非常的有效。

顶一个！