当然， Java 异常处理模型较 C++ 异常处理模型复杂的地方是，它引入了 finally 机制（主要用于数据库连接的关闭、 Socket 关闭、文件流的关闭等）。其实，我们也知道 finally 语法最早是在微软的 SEH 所设计出的一种机制，虽然它功能很强大，但是实现起来却并不是很难，从表象上来理解：当代码在执行过程中，遭遇到 return 和 goto 等类似的语句所引发作用域（代码执行流）转移时，便会产生一个局部展开（ Local Unwinding ）；而由于异常而导致的 finally 块被执行的过程，往往被称为全局展开（ Global Unwinding ）。由于展开（ Unwinding ）而导致的 finally 块被执行的过程，非常类似于一个子函数（或子过程）被调用的过程。例如，当在 try 块中最后一条语句 return 被执行到的时候，一个展开操作便发生了，可以把展开操作想象成，是编译器在 return 语句之前插入了一些代码（这些代码完成对 finally 块的调用），因此可以得出结论： finally 区域内的代码块，肯定是在 return 之前被执行。

但是，请特别注意， finally 块区域中的代码虽然在 return 语句之前被执行，但是 finally 块区域中的代码是不能够通过重新赋值的方式来改变 return 语句的返回值。请看如下的示例代码：

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

// 你认为 test 函数返回的值是多少呢？

System.out.println(\"test 的返回值为： \" + test());

}

public static int test()

{

int ret = 1;

try

{

System.out.println(\"in try block\");

// 是返回 1 ，还是返回 2 呢？

return (ret);

}

catch(Exception e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

}

finally

{

// 注意，这里重新改变了 ret 的值。

ret = 2;

System.out.println(\"in finally block!\");

}

return 0;

}

}

上面的示例程序中，本来是想在 finally 区域中通过改变 ret 的值，来影响 test 函数最终 return 的值。但是真的影响了吗？否！否！否！不信，看看运行结果吧！

in try block

in finally block!

test 的返回值为： 1

其实，在 SEH 异常处理模型中， try-finally 语句对此情况也是有相同结果的处理结果，同样是上面的那个程序，把它改称 C 语言的形式，用 VC 编译运行一把，验证一下结果，代码如下：

#include \"stdio.h\"

int test()

{

int ret = 1;

__try

{

printf(\"in try block
\");

return ret;

}

__finally

{

ret = 2;

printf(\"in finally block!
\");

}

return 0;

}

void main()

{

printf(\"test 的返回值为： %d
\", test());

}

通过调试可以很容易看出，在 return ret 之前，编译器实际上对 ret 赋值了一份临时变量，为的就是防止 finally 区域中的代码对这个 ret 值的改变。当然这只是 debug 版本的情况，实际上，在 release 版本， return ret 语句直接被编译器编译成 mov eax, 1 指令。

所以说，无论是在 SEH 异常处理模型中，还是 Java 的异常处理模型中， finally 块区域中的代码都是不能够通过重新赋值的方式来改变 try 区域中 return 语句的返回值。

强烈建议不要在 finally 内部使用 return 语句
上面刚刚说了， finally 块区域中的代码不会轻易影响 try 区域中 return 语句的返回值，但是有一种情况例外，那就是在 finally 内部使用 return 语句。示例程序如下：

// 示例程序 1 ， Java 程序

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

System.out.println(\"test 的返回值为： \" + test());

}

public static int test()

{

int ret = 1;

try

{

System.out.println(\"in try block\");

return (ret);

}

catch(Exception e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

}

finally

{

ret = 2;

System.out.println(\"in finally block!\");

// 这里添加了一条 return 语句

return ret;

}

}

}

// 示例程序 2 ， C 程序

#include \"stdio.h\"

int test()

{

int ret = 1;

__try

{

printf(\"in try block
\");

return ret;

}

__finally

{

ret = 2;

printf(\"in finally block!
\");

return ret;

}

printf(\" 多余的
\");

return 0;

}

void main()

{

printf(\"test 的返回值为： %d
\", test());

}

上面的程序运行结果如下：

in try block

in finally block!

test 的返回值为： 2

也许大多数朋友都估计到，上面的 test 函数返回值是 2 。也即是说， finally 内部使用 return 语句后，它影响（覆盖了） try 区域中 return 语句的返回值。这真是一种特别糟糕的情况，虽然它表面上看起来不是那么严重，但是这种程序极易给它人造成误解（使得阅读该代码的人总得担心或考虑，是否有 其它地方影响了这里的 return 的返回值）。

之所以出现这种现象的真正原因是，由于 finally 区域中的代码先于 return 语句（ try 作用域中的）被执行，但是，如果此时在 finally 内部也有一个 return 语句，这将会导致该函数直接就返回了，而致使 try 作用域中的 return 语句再也得不到执行机会（实际就是无效代码，被覆盖了）。

面对上述情况，其实更合理的做法是，既不在 try block 内部中使用 return 语句，也不在 finally 内部使用 return 语句，而应该在 finally 语句之后使用 return 来表示函数的结束和返回，把上面的程序改造一下，代码如下

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

try

{

System.out.println(\"test 的返回值为： \" + test());

}

catch(Exception e)

{

e.printStackTrace();

}

}

public static int test() throws RuntimeException

{

int ret = 1;

try

{

System.out.println(\"in try block\");

}

catch(RuntimeException e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

throw e;

}

finally

{

ret = 2;

System.out.println(\"in finally block!\");

}

// 把 return 语句放在最后，这最为妥当

return ret;

}

}

另一种更糟糕的情况
上面刚刚讲到， finally 内部使用 return 语句会覆盖 try 区域中 return 语句的返回值。不仅与此， finally 内部使用 return 语句还会导致出现另外一种更为糟糕的局面。到底是何种糟糕情况呢？还是先看看下面的示例程序再说吧！代码如下：

import java.io.*;

public class Trans

{

public static void main(String[] args)

{

try

{

System.out.println(\"test 的返回值为： \" + test());

}

catch(Exception e)

{

e.printStackTrace();

}

}

public static int test() throws RuntimeException

{

int ret = 0;

try

{

System.out.println(\"in try block\");

// 这里会导致出现一个运行态异常

int i=4,j=0;

ret = i/j;

}

catch(RuntimeException e)

{

System.out.println(\"in catch block\");

e.printStackTrace();

// 异常被重新抛出，上层函数可以进一步处理此异常

throw e;

}

finally

{

System.out.println(\"in finally block!\");

// 注意，这里有一个 return 语句

return ret;

}

}

}

是不是觉得上面示例程序中的代码写的挺好的，挺简洁的，还挺严谨的，应该不会有什么 BUG ！阿愚告诉你，错了！绝对错了！而且问题很严重！要不，朋友们在编译运行此程序前，先预期一下它的运行结果，大家是不是觉得运行流程应该是这样子的： 首先在终端输出“ in try block ”，接着，由于程序运行时出现了一个被 0 处的异常（ ArithmeticException ）；于是，进入到 catch block 中，这里的代码将继续向终端输出了“ in catch block ”信息，以及输出异常的堆栈信息等；接着，由于异常在 catch block 中又被重新抛出了，所以控制权返回到 main 函数的 catch block 中；对了，补充一点，也许大家会觉得，由于异常的 rethrow ，使得控制权离开 test 函数作用域的时候， finally 内的代码会被执行，也即“ in finally block ”信息也会被打印到终端上了 。仅仅如此吗？不妨看一下实际的运行结果，如下：

in try block

in catch block

java.lang.ArithmeticException: / by zero

at Trans.test(Trans.java:27)

at Trans.main(Trans.java:10)

in finally block!

test 的返回值为： 0

看了实际的运行结果，是不是觉得大吃一惊！被重新抛出（ rethrow ）的异常居然“丢弃了”，也即 main 函数中，并没有捕获到 test 函数中的任何异常，这也许大大出乎当初写这段代码的程序员的预料吧！究竟原因何在呢？其实， 罪魁祸首就是 finally block 内部的那条 return 语句 。因为这段程序的运行流程基本如刚才我们预期描述的那样，但是有一点是不对的，那就是当 test 函数中把异常重新抛出后，这将导致又一次的 catch 的搜索和匹配过程，以及 test 函数中的 UnWinding 操作，也即 finally 被调用执行，但是由于 finally 内部的 return 语句，不仅使得它结束了 test 函数的执行（并返回一个值给上层函数），而且这还使得上面的那个对异常进行进一步的操作过程给终止了（也即控制权进入到 catch block 的过程）。瞧瞧！后果严重吧！

是呀！如果 Java 程序员不注意这种问题，养成一个严谨的、好的编程习惯，它将会导致实际的许多 Java 应用系统中出现一些莫名奇妙的现象（总感觉系统中出现了某类异常，有一些问题，但上层的模块中却总是捕获不到相关的异常，感觉一些良好！其实不然，它完全 是由于 finally 块中的 return 语句不小心把异常给屏蔽丢弃掉了）。

总结
•     finally 区域内的代码总在 return 之前被执行；

按理说，一个方法执行到return就应该返回，但是按照Java的规范，finally中的代码又是一定要被执行的。
先看看上面这个程序的运行结果：

可以看到，虽然在try块中遇到了return，但finally中的代码仍然被执行了。test()方法的返回值最终为2。

那么try块中的return语句没有用吗？不是的。
如果你注释掉第8行，即finally中的return语句，你会发现test方法最终会返回1。结果如下：

发散一下，如果我在catch中返回一个值，同时也在finally中加入一个return语句，结果会怎么样呢？
答案是：现象相同。catch中的return和finally中的return都会执行。有兴趣的可以试试。

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2eehttp://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
 <display-name>
 TagStudy2
 </display-name>
 
  <jsp-config>
       <taglib>
           <taglib-uri>/hello</taglib-uri>
           <taglib-location>/WEB-INF/HelloTag.tld</taglib-location>
      </taglib>
   </jsp-config>
  

 <welcome-file-list>
  <welcome-file>default.jsp</welcome-file>
 </welcome-file-list>
 

</web-app>

从servlet2.4开始，taglib的uri是在标签库描述符中(tld)指定的，就像下面：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag 
Library 1.1//EN" "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
<taglib>
  <tlibversion>1.0</tlibversion>
  <jspversion>1.1</jspversion>
  <shortname>bean</shortname>
  
<uri>http://jakarta.apache.org/struts/tags-bean</uri>

任何需要使用这个标签库的页面都可以通过下面的页面级指令来引用它。标签库不需要再在web.xml文件中引用：
<%@ taglib
        uri="http://jakarta.apache.org/struts/tags-bean"
        prefix="bean" %>

下面一个表是struts标签的uri：