关于JavaException的基本知识和性能问题

异常：
1、多个catch块，父类异常必须放后面，子类放前面，如果是捕获多种异常，则cathch后面的异常变量隐藏了final，不能改变他的值，单个异常才可以。
2、catch、finally，不能独立存在，必须跟在try后面。但catch和finally需要存在其中一个，但是有种特别的隐藏，就是我们调用物理资源的时候，java7中，try中后面可以跟圆括号，里面实例化我们的资源变量。这样可以自动回收，但是声明的类必须实现两个接口，java7把一些普遍的物理资源类都进行了重写实现了。所以在这种情况下，可以没有catch和finally。
3、在catch中如果有throw和return，而且存在finally，则会先调用finally里面的内容。除非catch中能让程序中断或者结束。如果finally块中使用了return或者throw，将会导致try块，catch块的return、throw语句失效
4、java异常分为checked异常和runtime异常，checked异常是必须处理的异常，他可以提示调用者这里可能存在异常，checked异常只有在java中才有，我们在开发，可能这个方法是他人写的，他抛出checked异常就可以提示调用者。
5、使用throws声明抛出的异常的思路是，当前方法不知道如何处理这种类型的异常，该异常应该由上一级调用者处理；如果main方法也不知道如何处理这种类型的异常，也可以使用thorws声明抛出异常，该异常将交给JVM处理。JVM对异常的处理方法是，打印异常的跟踪栈信息，并中止程序运行，这就是程序在遇到异常后自动结束的原因。（方法出现异常，交给JVM）
6、个人理解在web中，异常出现而没有处理，交给JVM，然后异常信息打印到界面上。
7、自动关闭资源的try语句相当于包含了隐式的finally块
8、在catch中再次抛出异常，如果仅连接下面的catch串，是不会捕获的
异常处理规则：

对于完全已知的错误，应该编写处理这种错误的代码，增加程序的健壮性；对于普通的错误，应该编写处理这种错误的代码。只有对外部，不确定和预知的运行时错误才使用异常。（简单的话，业务逻辑判断速率会快点）

异常的基本概念图：

Throwable是所有异常的根，java.lang.Throwable
Error是错误，java.lang.Error
Exception是异常，java.lang.Exception

    在大学做项目的时候，当时的我经常用业务异常去处理我的逻辑，发现非常好用，而且异常的各种信息（自定义的信息）都能很好的返回给客户。可是在面试过程中当时被告知Java的Exception会带来很大性能消耗的问题，建议我不要使用异常去处理逻辑。所以在之后，我查业务异常可以用什么替代去解决性能的问题，在了解过后，学习到java的异常的性能的消耗大的原因是在于异常的基类：

Throwable.java的public synchronized native Throwable fillInStackTrace()方法。

方法介绍:

Fills in the execution stack trace. This method records within this Throwable object information about the current state of the stack frames for the current thread.

性能开销在于:
1. 是一个synchronized方法(主因)
2. 需要填充线程运行堆栈信息

但我们对于业务来说，只是为了填充我们的自定义消息和他的异常机制，不需要这个堆栈的信息，如果去掉这个堆栈的信息，性能将会提升。我们只要重写fillInStackTrace()方法，并且去掉同步，性能会极大的提升。并且try、catch  和 if、else的性能开销是同一个数量级的。