Java异常处理机制：try-catch
try{
代码片段
}catch(XXXException e){
处理try代码片段中出现的xxxException
}catch（Exception e）{
...
}通常在最后一个catch中捕获Exception，防止中断
try的（）中只能定义实现了Autocloseable接口的内容。否则会出现编译不通过的情况，最终编译器会将代码改为在finally中关闭这里定义的需要关闭的内容。
何时使用throw抛出一个异常
1.通常遇到以下两种情况时我们会抛出异常
1.1 当程序遇到一个满足语法但是不满足业务逻辑的运行情况时，可以主动实例化一个异常抛出给调用这个以告知这种情况不允许；
1.2 程序确实出现了一个异常，但是该异常不应当在当前代码段中被解决，可以对外继续抛出异常当一个方法中使用throw抛出某个异常时，就要使用throws关键字在声明方法的同时声明该异常的抛出，以通知调这处理异常只有RuntimeException。在方法中泡壶时可以不在方法上声明该异常的抛出，除此之外的其他异常则是必须的，否则编译不通过。
当我们调用一个含有throws声明异常抛出的方法时就必须处理该异常，否则编译不通过。处理手段有两种：
1. 使用try-catch处理该异常
2. 在当前方法上继续对外抛出取决与业务需求的责任问题，视具体情况而定，不应当在main方法上使用throws声明异常的抛出。
子类在重写父类含有throws声明异常抛出的方法时对于throws的重写准则。
1. 允许抛出部分异常
2. 允许不再抛出任何异常
3. 允许抛出父类方法抛出异常的子类型异常
4. 不允许抛出其他异常
5. 不允许抛出父类方法抛出异常的父类型异常RuntimeExcepotion
非检测异常，因为普通JVM操作引起的运行时异常随时可能发生，此类异常一般是由特定操作引发，但这些操作在java应用程序中会频繁出现。因此它们不受编译器检查与处理或声明规则的限制。
常见RuntimeException
IllegalArgumentException 传递不合法或者不正确的参数
NullPointerExcepiton 空引用
ArrayIndexOutOfBoundsException 使用的数组下标超出数组允许范围
ClassCastException 强制转换为不是实例的子类
NumberFormatException 应用程序视图将字符串转换成一种数值类型，但不能转为适当格式时，抛出该异常
Exception常用API
e.printStackTrace();
e.getMessage();
getCause();检查异常导致的原因
12.12.3把“被检查的异常”转换为“不检查的异常”
在编写自己使用的简单程序时，从main()中抛出异常很方便的，但这不是通用的方法。问题的实质是，当在一个普通方法里调用别的方法时，要考虑到“我不知道该这样处理这个异常，但是也不想把它‘吞’了，或者打印一些无用的信息”。JDK1.4的异常链提供了一种新的思路来解决这个问题。可以直接把“被检查的异常”包装进RuntimeExcepiton里面，就像这样：
try{
// ... to do something useful
}catch(IDontKnowWhatTODoWithThisCheckedException e){
throw new RuntimeException(e);
}如果想把“被检查的异常”这种功能“屏蔽”掉的话，这看上去像是一个好办法。不用“吞下”异常，也不必把它放到方法的异常说明里，而异常链还能保证你不会丢失任何原始异常的信息。
这种技巧给了你一种选择，你可以不写try-catch字句和/或异常说明，直接忽略异常，让它自己沿着调用线往上“冒泡”。同时，还可以用getCause()捕获并处理特定的异常。
异常使用指南
应该在下列情况下使用异常
- 在恰当的级别处理问题（在知道该如果处理的情况下才捕获异常）
- 解决问题并且重新调用产生异常的方法
- 进行少许修补，然后绕过异常发生的地方继续执行
- 用别的数据进行计算，以代替方法预计会返回的值
- 把当前运行环境下能做的事情尽量做完，然后把相同的异常抛到更高层
- 把当前运行环境下能做的事情尽量做完，然后把不同的异常抛到更高层
- 终止程序
- 进行简化。（如果你的异常模式使问题变得太复杂，那用起来会非常痛苦也很烦人。）
- 让类库和程序安全。（这既是在为调试做短期投资，也是在为程序的健壮性做长期投资。）