try catch finally throw,throws 平时我们开发中用的很多，但是里面的具体执行顺序 发现自己还是不是很清晰，百度了一些博客，然后结合自己的实践，
总结了一下,便于自己以后查看。同时也希望对看到这篇文章的朋友有点帮助。如有错误请在评论区留言，谢谢。
首先我们简历控制台程序测试。
1-看第一种情况
执行结果：
然后catch中不抛异常
2-假设我们不想在fun1方法中处理异常，想把异常继续抛给调用者（这里指的是Main方法）让他们去处理这个异常，那么这时候就要用到throw,throws 了
将fun0 方法改造：
throw 的执行结果：
throw e的执行结果：
通过以上的结果我们可以总结到：
0-无论catch中有没有抛异常，finally中的代码块都会执行。
1-catch不使用throw / throws， 执行catch中的代码-》finally中的代码=》finally外部后续代码会继续执行=》方法结束
2-catch中使用throw / throws， 执行catch中的代码=》遇到了throw, throw后面的代码不执行了，然后执行finally中的代码，
执行完后回到catch中 通过throw 将代码抛给上一个直接调用层 方法直接结束。finally外部后续的代码也不执行了。
但是！我们发现上面的throw 和 throws都是返回的结果都是一样的 那么他们的执行结果到底是什么呢？
继续修改代码。
75行我们用throw / throw e两种写法
throw 结果：
显示了完整的堆栈信息，知道产生错误的最开始的那行代码位置。
throw e结果：
会在throw e的时候把之前的异常堆栈清空，然后只显示当前产生异常的代码位置。
总结：throw e会清空之前的异常堆栈，throw 会显示完整的堆栈信息。
在正常开发中我们可能写接一个接口会调用别人的信息，这时候你可能会提前判断可能会产生异常，这时候你可以有两种选择。
1-throw出去，让调用者自己去处理。2-你自己的catch代码块里面处理(比如记录日志啥的)。
我们来看下 如果throw e现实开发中会出现什么问题。
程序猿A 写了一个接口1 然后他预判到可能会有异常 然后在代码里面catch 然后throw e ，
这时候程序猿B 去调用了A的代码 报了异常，那这时候可能只会显示说A的那个接口方法出问题了，不会显示具体哪里出了问题。
这时候如果A的接口1 写了很复杂的逻辑 B通知A说 你快去看看你的接口为啥报异常了 那这时候A是不是很苦逼的分析代码，悔不当初啊。
所以A要么直接throw把完整的堆栈信息抛给掉的那一层， 要么直接自己处理异常(比如 将异常信息的堆栈信息记录在日志里面，那么到时候别人调用了A的接口出了问题是不是就可以通过看日志很快分析出原因了)所以都是一些细节问题，自己要注意。
--继续补充，说一下 catch 结合return的这种情况。
结果：
虽然finally里面改变了a的值但是返回的还是catch的a的值，说明catch返回a的时候已经确定了a的值所以finally改变a的值无效。
备注：finally 里面不能写return语句编译器会报错。
编译器对值类型a是这样处理的，那我们看下引用类型会发生什么。继续贴代码。
写法1：
输出结果：
写法2：
输出结果：
发现区别了么，说明在catch中返回值类型和引用类型，编译器处理的机制是不一样的。
最后以我自己的理解说下为什么要有finally这个关键字。因为finally不管有没有执行catch，finally都是会执行的。
在我们开发过程中，会有一些文件操作，数据库连接。如果报了异常，我们这时候肯定是要去关闭文件流的，以及将关闭数据库连接，然后将连接返回给数据库连接池，
这就是为什么我们经常强调说要在finally里面关闭文件流/关闭数据库连接，这样是为了怕批量发生异常的时候，不关闭文件流以及数据库连接那就会一直占用资源，
这样对我们应用服务器，数据库服务器性能产生不好的影响。所以要养成这种好习惯。
----End 转载请注明出处