Java异常
在Java中，一个异常对象总是Throwable子类的实例。
Error类体系描述了Java运行系统中的内部错误以及资源耗尽的情况。
由编程导致的错误，会导致RuntimeException异常。而其他错误原因导致的异常----例如，因为I/O错误导致的曾经运行正确的程序出错，都不会导致RuntimeException异常。
从RuntimeException衍生出来的异常包括下面的问题：1〉错误的类型转换；2〉数组越界访问；3〉试图访问一个空指针。
不是从RuntimeException衍生出来的异常包括：
1〉试图从文件尾后面读取数据；
2〉试图打开一个错误格式的URL；
3〉试图用一个字符串来构造一个Class对象，而当该字符串对应的类并不存在；
处理RuntimeException的原则是：如果出现RuntimeException，则一定是你的错误；
不同的浏览器可以处理不同类型的URL，所以，URL格式是否错误依赖于具体的环境，而不仅仅是程序代码；
Java语言规范中将任何Error的子类以及RuntimeException的子类都称为未检查异常，而其他的异常则称为已检查异常；
仅仅在以下4种情况下，才会抛出异常：
1〉调用了一个会抛出"已检查异常"的方法，例如BufferReader类的readLine方法；
2〉程序运行过程中发生了错误，并且用throw语句抛出一个"已检查异常"；
3〉程序错误，例如a[-1]=0会抛出一个"未检查异常"如数组下标越界(ArrayIndex--OutOfBoundsException)；
4〉Java虚拟机或者是运行时库出现了内部错误；
不需要声明Java的内部错误。一个方法必须声明它可能抛出的全部"已检查异常"。如果在自己的子类中覆盖了一个来自父类的方法。特别需要注意的是，如果父类方法根本没有抛出任何"已检查异常"，则子类也只能如此；
在Java中，没有throws指示符的方法是不能抛出任何已检查Java异常的；
对于try/catch代码块，如果方法内的任何代码抛出了一个异常，同时它的类型没有在catch中指定，则方法会立即退出；
应捕捉并且处理那些已知如何处理的异常(用catch)，而传递那些不知如何处理的异常(用throws);
对于try/catch/finally代码块，无论是否捕获异常，都会执行finally从句中的代码；
虽然Java程序员必须在finally从句中人工设置代码来回收资源，但由于Java内建有"垃圾收集"机制，所以只有极少数的资源才要求人工进行回收；
actionPerformed方法不能抛出任何已检查异常；
使用Java异常机制的一些技巧：
1〉异常控制不能代替简单的测试，和执行简单的测试相比，捕捉异常所需的时间大大超过前者，所以，只有在异常情况下才使用异常；
2〉不要过分细化异常；
3〉不要压制异常：可以使用如下格式: try { //代码 } catch (Exception e) { //空 }
4〉不要羞于传递异常：对于某些异常(如调用FileInputStream构造器或者readLine方法产生的异常)，传递它比捕捉它更好。让高层的方法来通知用户发生了错误或者放弃执行不成功的命令更合适。
Java断言
默认情况下，Java断言是关闭的。可通过-ea来打开，用-da来关闭。选项-ea:...会打开默认包中全部类的断言功能，打开或者关闭断言是类装载器的功能；
-da和-ea选项对那些没有类加载器的"系统类"是不起作用的。对于这些系统类，要使用-enablesystemassertions/-esa选项来打开断言功能；
Java断言使用技巧：
1>断言失败是致命的，不可恢复的错误；
2>断言检查仅仅用在程序开发和测试阶段；
因此，不应该用断言作为信号来通知程序的另外部分发生了可恢复错误，或者将断言作为通知程序使用者的方式。Java断言仅仅应该在测试阶段用来定位程序内部错误；
Java断言是在测试和调试阶段使用的工具，而日志是在程序整个生命周期中都使用的策略性工具。
下面是think in java中的一段
违例准则
用违例做下面这些事情：
(1) 解决问题并再次调用造成违例的方法。
(2) 平息事态的发展，并在不重新尝试方法的前提下继续。
(3) 计算另一些结果，而不是希望方法产生的结果。
(4) 在当前环境中尽可能解决问题，以及将相同的违例重新“掷”出一个更高级的环境。
(5) 在当前环境中尽可能解决问题，以及将不同的违例重新“掷”出一个更高级的环境。
(6) 中止程序执行。
(7) 简化编码。若违例方案使事情变得更加复杂，那就会令人非常烦恼，不如不用。
(8) 使自己的库和程序变得更加安全。这既是一种“短期投资”（便于调试），也是一种“长期投资”（改善应用程序的健壮性）
