也就是说在将message设置为true时，会去request中寻找Globals.MESSAGE_KEY所代表的bean，然而我们在具体的Action使用ActionMessages类的时候往往是这样的
ActionMessages messages = getErrors(request);
messages.add(ActionMessages.GLOBAL_MESSAGE , new ActionMessage(key , value0));
saveMessages(request,messages);

而往往困扰人的就在于为什么要给messages中放入名称为"ActionMessages.GLOBAL_MESSAGE"的ActionMessage对象，而且还需要再次的调用saveErrors(request,messages)方法？

首先要说明的是你为ActionMessage起任何的名称都没有关系，因为ActionMessages本身维持着一个HashMap，而参数property就是这个HashMap中的key值，如果不存在则会建立相应的key,并将需要保存的ActionMessage对象存入到这个key所对应的List中。
    public void add(String property, ActionMessage message) {

        ActionMessageItem item = (ActionMessageItem) messages.get(property);
        List list = null;

        if (item == null) {
            list = new ArrayList();
            item = new ActionMessageItem(list, iCount++, property);

            messages.put(property, item);
        } else {
            list = item.getList();
        }

        list.add(message);

    }

至于为什么一定要调用saveMessages(request,messages)？看看它具体的实现逻辑就清楚了
    protected void saveMessages(
        HttpServletRequest request,
        ActionMessages messages) {

        // Remove any messages attribute if none are required
        if ((messages == null) || messages.isEmpty()) {
            request.removeAttribute(Globals.MESSAGE_KEY);
            return;
        }

        // Save the messages we need
        request.setAttribute(Globals.MESSAGE_KEY, messages);
    }

再对比前面介绍的messagesPresent标签的使用，是不是就清楚了呢？原来它是将ActionMessages对象保存在request中，并且名称是Globals.ERROR_KEY！从而为tag的顺利解析铺平了道路。当然按理你可以选择将这样的对象放置在任何的scope中，但Action只是提供了request , session两种Scope（不过page , application不经常使用，可以理解，但不提供相应的结构就不太好了）

至于messagesPresent标签是如何在scope中寻找ActionMessages对象

org.apache.struts.taglib.logic.MessagesPresentTag
    protected boolean condition(boolean desired) throws JspException {
        ActionMessages am = null;

        String key = name;
        if (message != null && "true".equalsIgnoreCase(message)){
           key = Globals.MESSAGE_KEY;
        }

        try {
            am = TagUtils.getInstance().getActionMessages(pageContext, key);
           
        } catch (JspException e) {
            TagUtils.getInstance().saveException(pageContext, e);
            throw e;
        }

        Iterator iterator = (property == null) ? am.get() : am.get(property);

        return (iterator.hasNext() == desired);

    }

org.apache.struts.taglib.TagUtils
   public ActionErrors getActionErrors(PageContext pageContext, String paramName)
            throws JspException {

        ActionErrors errors = new ActionErrors();

        Object value = pageContext.findAttribute(paramName);
        if (value != null) {
            try {
                if (value instanceof String) {
                    errors.add(
                            ActionMessages.GLOBAL_MESSAGE,
                            new ActionMessage((String) value));

                } else if (value instanceof String[]) {
                    String keys[] = (String[]) value;
                    for (int i = 0; i < keys.length; i++) {
                        errors.add(
                                ActionMessages.GLOBAL_MESSAGE,
                                new ActionMessage(keys[i]));
                    }

                } else if (value instanceof ActionErrors) {
                    errors = (ActionErrors) value;

                } else {
                    throw new JspException(
                            messages.getMessage(
                                    "actionErrors.errors",
                                    value.getClass().getName()));
                }

            } catch (JspException e) {
                throw e;

            } catch (Exception e) {
                log.debug(e, e);
            }
        }
        return errors;
    }

PageContext中的findAttribute会帮你在scope中寻找名称为Globals.MESSAGE_KEY的ActionMessage对象。


注意
虽然Struts已经声明：不推荐使用ActionErrors & ActionError对象，但在一些遗留的系统中，依然还是可以看到其影子，所以如果你的系统不幸属于这样的两种混合系统，有以下的几种方法可以参考
1。两次调用messagesPresent，如下
<!-- Print ActionErrors Object -->
<logic:messagesPresent>
  <html:messages id="msg" message="true">
    <div class="success">
      <bean:write name="msg"/>
    </div><br/>
  </html:messages>
</logic:messagesPresent>

<!-- Print ActionMessages Object -->
<logic:messagesPresent message="true">
  <html:messages id="msg" message="true">
    <div class="success">
      <bean:write name="msg"/>
    </div><br/>
  </html:messages>
</logic:messagesPresent>

2.分别使用<html:messages> <html:errors>标签，当然在老系统中需要调用Action的saveErrors方法，而在新的应用中要调用saveMessages方法。

3.更换所有的ActionErrors为ActionMessages,并将所有调用saveErrors的地方更换成saveMessages，并将<html:errors>标签相应的更换成<html:messages message="true"> － 推荐！

从开发项目的类别角度看java平台

基于B/S结构的系统，在这个方向上的竞争是激烈的，有专注于此的LAMP（Linux + Apache + Mysql + Php）;也有刚刚兴起的Rails（Ruby Frameworks）甚至是号称快速开发的ASP.NET;当然了java在这个领域里的MVC框架数都数不完，比如Struts . Webwork等，然而即便是如此，选择java作为开发的理由也是不充分的，因为在这个梯队里java顶多排名最后。

基于C/S结构的系统，在这个方面java显然没有考虑周到，面对VB 、DELPHI、vc这些个如狼似虎的快速开发IDE，JAVA实在是显得异常的淡薄，即使你找到了一个可以匹敌这些个ide的工具，面对第三方的组件又会成为一大障碍，所以java在这个方面又一次的输了。

从java所强调的特性角度看java平台

java的重点是业务逻辑！（我以前也是如此坚信不移）可是谁有能够说别的语言不注重业务逻辑呢，业务逻辑只是一个抽象的概念，java只是依靠ejb提出了业务组件而已，其他的语言在实现业务逻辑的时候也可以包装成POJO的形式，看来这个观点也是失败的。

java强调的是跨平台的优势！这可以理解为初级的、商业的、忽悠人的词汇，面对众多动态语言如Python，在若干平台上的表现，java又如何来强调自己这方面的优势呢？失败

java支持分布式应用的项目！可笑的言论，分布式根本不是值得炫耀的资本，在java之前的c/s项目中何尝不是分布式的应用呢？失败

既然没有了这些个优势，我们看看java到底还剩下些什么？对了其实就是应用服务器！然而看过J2EE WITHOUT EJB的读者肯定知道Spring所希望达到的目的，也就是脱离应用服务器概念上的J2EE体系实现，既然在作者的眼里APPLICATION SERVER只不过是一个忽悠人的词汇，那么任何项目都选择java作为开发的依据显然就是自找苦吃，

那么什么情况下改选择java作为开发的平台呢？
<1> 如果你真的遇到了大型的系统开发任务，恭喜你，你终于可以看到分布式对象、集群的优势了。
<2> 客户是一个java的忠实fans或者是sun、ibm的金牌合作伙伴之类的，选择java是不得已的，但记住并不能证明java是最好的实现方式
<3> 如果你只想关心业务逻辑的实现，对于事务、缓存、查找等服务的实现没有兴趣的话，倒是不妨考虑采用ejb的形式，当然前提是你不愿意在寻找合适的替代品的情况下。
<4> 如果项目迫切的寻找某种框架的支持，选择java就是对的，你有众多优秀的、免费的、可扩展的、天才的框架可以选择，更多的时候你是出于尴尬的境地，因为任何一个都让你心动、而这样的选择往往是最痛苦、和快乐的。

正确的选择
<1>
条件: 如果项目仅仅只是一个小型的网站系统
选择: LAMP、Rails

<2>
条件: 项目规模中等
并且项目的时间比较紧，
项目可以架构在windows的系统之上，
选择: .Net  / Delphi

<3>
条件: 大型的系统，有支持分布式对象、集群的要求；或者SUN / IBM的金牌合作伙伴 ; 想要寻找某种优秀的框架来解决问题
选择: java是不二的选择，可是我想问一下，在现实中你能遇到这样的项目吗？

所以，从实际的角度出发，我们面对的99％可能都是一些符合条件1，2的系统，而选择java实在是得不偿失的。最后以一段Code Complete中的话来作为结束语

每个程序员都有很多的工具，但并不存在任何一个能够适用于所有工作的工具，因地制宜的选择正确工具是成为能有效编程的程序员的关键。

JUnit 是 Java™ 语言事实上的 标准单元测试库。JUnit 4 是该库三年以来最具里程碑意义的一次发布。它的新特性主要是通过采用 Java 5 中的标记（annotation）而不是利用子类、反射或命名机制来识别测试，从而简化测试。在本文中，执着的代码测试人员 Elliotte Harold 以 JUnit 4 为例，详细介绍了如何在自己的工作中使用这个新框架。注意，本文假设读者具有 JUnit 的使用经验。

JUnit 由 Kent Beck 和 Erich Gamma 开发，几乎毫无疑问是迄今所开发的最重要的第三方 Java 库。正如 Martin Fowler 所说，“在软件开发领域，从来就没有如此少的代码起到了如此重要的作用”。JUnit 引导并促进了测试的盛行。由于 JUnit，Java 代码变得更健壮，更可靠，bug 也比以前更少。JUnit（它本身的灵感来自 Smalltalk 的 SUnit）衍生了许多 xUnit 工具，将单元测试的优势应用于各种语言。nUnit (.NET)、pyUnit (Python)、CppUnit (C++)、dUnit (Delphi) 以及其他工具，影响了各种平台和语言上的程序员的测试工作。

然而，JUnit 仅仅是一个工具而已。真正的优势来自于 JUnit 所采用的思想和技术，而不是框架本身。单元测试、测试先行的编程和测试驱动的开发并非都要在 JUnit 中实现，任何比较 GUI 的编程都必须用 Swing 来完成。JUnit 本身的最后一次更新差不多是三年以前了。尽管它被证明比大多数框架更健壮、更持久，但是也发现了 bug；而更重要的是，Java 不断在发展。Java 语言现在支持泛型、枚举、可变长度参数列表和注释，这些特性为可重用的框架设计带来了新的可能。

JUnit 的停滞不前并没有被那些想要废弃它的程序员所打败。挑战者包括 Bill Venners 的 Artima SuiteRunner 以及 Cedric Beust 的 TestNG 等。这些库有一些可圈可点的特性，但是都没有达到 JUnit 的知名度和市场占有份额。它们都没有在诸如 Ant、Maven 或 Eclipse 之类的产品中具有广泛的开箱即用支持。所以 Beck 和 Gamma 着手开发了一个新版本的 JUnit，它利用 Java 5 的新特性（尤其是注释）的优势，使得单元测试比起用最初的 JUnit 来说更加简单。用 Beck 的话来说，“JUnit 4 的主题是通过进一步简化 JUnit，鼓励更多的开发人员编写更多的测试。”JUnit 4 尽管保持了与现有 JUnit 3.8 测试套件的向后兼容，但是它仍然承诺是自 JUnit 1.0 以来 Java 单元测试方面最重大的改进。

注意：该框架的改进是相当前沿的。尽管 JUnit 4 的大轮廓很清晰，但是其细节仍然可以改变。这意味着本文是对 JUnit 4 抢先看，而不是它的最终效果。

以下是robbin的观点

如果说不使用Session Facade模式的话，我认为EB还是一个很有意义的的东西，因为EB是唯一直接支持跨RMI的持久化方案。但是由于EB的效率和减少跨RMI的网络调用的原因，EB已经完全被封装到SB的后面，EB的分布式调用的功能，EB的安全验证功能，EB的容器事务功能完全被前面的SB给做了，结果EB就只剩下了唯一的ORM功能了，单就ORM这一点来说EB实在是一个非常非常糟糕的东西。那么EB还有什么功能值得我非去用它不可呢？

用 Session Bean + DAO + Hibernate 来取代 Session Bean + Entity Bean，不但能够极大降低软件设计难度，软件开发难度，软件调试难度和软件部署难度，而且还可以提高允许效率，降低硬件要求。

不要把EB直接拿来和Hibernate做比较，两者不是一个范畴的东西，而应该整体比较两种方案：
Session Bean + DAO + Hibernate
Session Bean + Entity Bean
我找不出来第二方案有哪怕一点方面能够比第一方案好的。

CMP可以使用CMR来表示多表之间通过外键关联的关系。但是你仍然会遇到即使没有键关联的表仍然需要连接查询的情况，这是一个非常普遍的现象。

如果是Hibernate，可以在HSQL里面定义outer join，BMP也可以写JDBC，而CMP没有任何办法来解决该问题，除非你把需要的连接查询都定义为CMR，但那样的话，凡是有需要连接查询，或者有键关联的表都必须打在一个包里面。你如果不打在一个jar包里面，如果能够建立CMR？不是我想放在一个jar里面，而是不得不放在一个jar里面。基本上CMP还是非常笨拙的。

CMP的另一大缺点是不能动态SQL，guty已经提到了，一个SQL就要定义一个EJBFinder方法，在编译的时候就确定死了。在实际应用中，经常会遇到不确定查询条件的查询，比如说用户在页面上用下拉列表来选择查询的条件，用户既有可能什么限制条件都不选，也有可能选择某几个条件。这时候你怎么办？假设有n个查询条件，你要写 C1n + C2n + C3n +...+ Cnn(C是组合公式的符合，n是下标，1...n是上标)个EJBFinder方法才行，很恐怖吧。

其实JDBC的PrepareStatement也不能很好的解决这个问题，因为它是按照1，2这样的次序来set参数的。用Statement是肯定不行的，会严重影响数据库，甚至会导致数据库down掉(我的实际经验)。但是Hibernate就解决的不错，因为它可以按照 :name 这样的形式来设定SQL中的Placeholder，这样set参数就可以按照参数名称传递，因为次序不是死的，在程序里面就很容易根据用户选择的查询条件，动态的产生SQL，动态的set参数了。

CMP2.0还有一个大问题是不支持order by，当然你可以在Java里面对取出来的集合排序，但是速度和数据库里面就排好序速度不在一个数量级了。Hibernate不但可以order by，还可以group by，having，子查询，真是没有办法比下去了。

其实对于动态SQL和排序问题，特定的App Server也可以做，但那不是CMP2.0的规范罢了，所以为了可移植性，也不敢随便去用。

在项目开发时， 开发和运行效率以及灵活性是非常重要的指标。由于Entity Bean天生是一种粗粒度的使用方式，这就必定使它在装载的时候有较长的响应时间，也不能自如的支持懒装入的方式，使用成细粒度会使程序变得复杂，以及远程调用细粒度的entity bean是一种非常可怕的行为, 太慢了.

Hibernate正好满足开发和运行效率以及灵活性，说来说去，它可以称做一个OO化的JDBC, 这样大家就不会对Hibernate产生误解及恐惧心理。它支持粗细两种粒度方式，运用起来灵活自如，前提是你必知道如何使用，一个entity bean 实现要N种重复的方法, such as ejbRemove,ejbstore,ejb...., 光类也有一大堆，象Home Interface, Romote Interface..., Primary class if necessary. Hibernate只需要一个就行了。

CMP在进行O/R Mapping方面只是做了最基础的工作而已，完全用CMP做数据层，会发现你在把数据库应该做的工作全部都搬到App Server里面来重新实现一遍，有这必要吗？

CMP是把EJBQL写死在ejb-jar.xml里面的，所以n个条件就需要(c0n+c1n+...cnn )2的n次方个EJBFinder方法，简直没有办法说。

JDBC实现PrepareStatement的动态SQL构造不是不能够，而是非常麻烦，需要写一个非常非常大的if elseif else嵌套的判断。

Hibernate实现起来特别简单，（其实OJB也实现了PrepareStatement的动态SQL构造）这本身并不复杂，但是需要你多写些代码而已，由于CMP把EJBQL写死在配置文件里面了，你连选择的余地都没有。

To answer the question I started with the JavaDoc for the Class.forName() method. According to the documentation, the method:

... attempts to locate, load, and link the class or interface

Loading refers to the process of finding the binary form of a class or interface type with a particular name, perhaps by computing it on the fly, but more typically by retrieving a binary representation previously computed from source code by a compiler, and constructing, from that binary form, a Class object to represent the class or interface.

So then back to the original problem, when Class.forName() is called with an argument like this:

Class.forName("org.gjt.mm.mysql.Driver");

the classloader attempts to load and link the Driver class in the "org.gjt.mm.mysql" package and if successful, the static initializer is run. The MySQL Driver (download the source code) static initializer looks like this:

static {
  try {
    java.sql.DriverManager.registerDriver(new Driver());
  } catch (SQLException E) {
    throw new RuntimeException("Can't register driver!");
  }
}

So it calls a static method in the java.sql.DriverManager class which apparently registers a copy of itself when it loads.

So now I understand the where and the how, what about why? To understand the why you have to look at the next line in the initial code example:

Connection con = DriverManager.getConnection(url,
  "myLogin", "myPassword");

The DriverManager class (view DriverManager source here) returns a database connection given a JDBC URL string, a username and a password. In order to create that connection, the DriverManager class has to know which database driver you want to use. It does that by iterating over the array (internally a Vector) of drivers that have registered with it (ie: the registerDriver(Driver driver) method illustrated above) and calls the acceptsURL(url)) method on each driver in the array, effectively asking the driver to tell it whether or not it can handle the JDBC URL.

So there you have it. Class.forName explained.

这里有一份详细的参考资料：

关于Java栈与堆的思考 http://www.javafan.net/article/20051123115654293.html

Here's a list of keywords in the Java language. These words are reserved — you cannot use any of these words as names in your programs. true, false, and null are not keywords but they are reserved words, so you cannot use them as names in your programs either.

abstract    |   continue    |   for    |    new     |   switch
assert***  |   default     |   goto*     |   package     |   synchronized
boolean    |   do     |   if     |   private     |   this
break         |   double     |   implements    |   protected    |   throw
byte            |   else     |   import     |   public  throws
case          |   enum****    |   instanceof    |   return     |   transient 
catch         |   extends     |   int     |   short     |   try
char           |   final     |   interface    |   static     |   void
class         |   finally     |   long     |   strictfp**    |   volatile
const*       |   float     |   native     |   super     |   while

*   not used
**   added in 1.2
***   added in 1.4 
****   added in 5.0                                    

Key: strictfp^**

使用对象：类、方法

自Java2以来，Java语言增加了一个关键字strictfp，虽然这个关键字在大多数场合比较少用，但是还是有必要了解一下。

strictfp的意思是FP-strict，也就是说精确浮点的意思。在Java虚拟机进行浮点运算时，如果没有指定strictfp关键字时，Java的编译器以及运行环境在对浮点运算的表达式是采取一种近似于我行我素的行为来完成这些操作，以致于得到的结果往往无法令你满意。而一旦使用了strictfp来声明一个类、接口或者方法时，那么所声明的范围内Java的编译器以及运行环境会完全依照浮点规范IEEE-754来执行。因此如果你想让你的浮点运算更加精确，而且不会因为不同的硬件平台所执行的结果不一致的话，那就请用关键字strictfp。

你可以将一个类、接口以及方法声明为strictfp，但是不允许对接口中的方法以及构造函数声明strictfp关键字，例如下面的代码：

1. 合法的使用关键字strictfp

strictfp interface A {}

public strictfp class FpDemo1 {
    strictfp void f() {}
}

2. 错误的使用方法

interface A {
    strictfp void f();
}

public class FpDemo2 {
    strictfp FpDemo2() {}
}

一旦使用了关键字strictfp来声明某个类、接口或者方法时，那么在这个关键字所声明的范围内所有浮点运算都是精确的，符合IEEE-754规范的。例如一个类被声明为strictfp，那么该类中所有的方法都是strictfp的。

Keys: volatile

使用对象：字段

介绍：因为异步线程可以访问字段，所以有些优化操作是一定不能作用在字段上的。volatile有时

可以代替synchronized。

Keys：transient

　　使用对象：字段

　　介绍：字段不是对象持久状态的一部分，不应该把字段和对象一起串起。

 记得当初参与某公司的ERP项目中，接触过异常框架这个概念，可是似乎并没有感觉到当时技术经理提出这个概念的意义，而且他也对这个概念似乎很"保守"，虽然按照他的思路去执行，但没有理解的概念再实施起来的时候总是觉得很"别扭"，而如今面对自己要设计咚咚了，不得不重新审视异常这个概念，JAVA异常的介绍文章在网络上非常的少，而对于如何构件J2EE的异常处理框架更显的稀少，于是就促使自己写下了这样的文章。

 本文只是自己的一些愚见，希望和大家相互学习。Email:Killvin@hotmail.com

概念

什么是异常？

异常（exception）应该是异常事件（exceptional event）的缩写。
异常定义：异常是一个在程序执行期间发生的事件，它中断正在执行的程序的正常的指令流。
当在一个方法中发生错误的时候，这个方法创建一个对象，并且把它传递给运行时系统。这个对象被叫做异常对象，它包含了有关错误的信息，这些信息包括错误的类型和在程序发生错误时的状态。创建一个错误对象并把它传递给运行时系统被叫做抛出异常。
一个方法抛出异常后，运行时系统就会试着查找一些方法来处理它。这些处理异常的可能的方法的集合是被整理在一起的方法列表，这些方法能够被发生错误的方法调用。这个方法列表被叫做堆栈调用（call　stack）

运行时系统搜寻包含能够处理异常的代码块的方法所请求的堆栈。这个代码块叫做异常处理器，搜寻首先从发生的方法开始，然后依次按着调用方法的倒序检索调用堆栈。当找到一个相应的处理器时，运行时系统就把异常传递给这个处理器。一个异常处理器要适当地考滤抛出的异常对象的类型和异常处理器所处理的异常的类型是否匹配。异常被捕获以后，异常处理器关闭。如果运行时系统搜寻了这个方法的所有的调用堆栈，而没有找到相应的异常处理器。

怎么设计异常框架

任何的异常都是Throwable类（为何不是接口？？），并且在它之下包含两个字类Error / Exception，而Error仅在当在Java虚拟机中发生动态连接失败或其它的定位失败的时候，Java虚拟机抛出一个Error对象。典型的简易程序不捕获或抛出Errors对象，你可能永远不会遇到需要实例化Error的应用，那就让我们关心一下Exception

Exception中比较重要的就是RuntimeException－运行时异常（当然这个名字是存在争议的，因为任何的异常都只会发生在运行时），为什么说这个类时很重要的呢？因为它直接关系到你的异常框架的设计，仔细看RuntimeException

A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

－可能在执行方法期间抛出但未被捕获的 RuntimeException 的任何子类都无需在 throws 子句中进行声明。

也就是说你的应用应该不去“关心”（说不关心是不服责任的，但只是你不应该试图实例化它的字类）RuntimeException，就如同你不应该关心Error的产生与处理一样！RuntimeException描述的是程序的错误引起来的，因该由程序负担这个责任！（<B>从责任这个角度看Error属于JVM需要负担的责任;RuntimeException是程序应该负担的责任;checked exception 是具体应用负担的责任</B>）

那就有人会问，那我该关心什么！答案就是除了Error与RuntimeException，其他剩下的异常都是你需要关心的，而这些异常类统称为Checked Exception,至于Error与RuntimeException则被统称为Unchecked Exception.

异常的概念就这些了，即使你在网络上搜索也就不过如此，是不是感觉到有点清晰又有点模糊？那么怎么该如何在这样单薄而模糊的概念下设计J2EE的异常框架呢？

解决方案：J2EE异常框架

我们拿一个模拟的例子来说明异常框架的设计过程，比如我们要对外提供doBusiness()这个业务方法

public void doBusiness() throws xxxBusinessException

当客户端调用这样的方法的时候应该这样处理异常（包括处理RuntimeException , checked exception）
<B>记住，无论如何我们都不希望或者确切的说是不应该将RuntimeException这样的异常暴露给客户的，因为他们没有解决这个问题的责任！</B>
我们暂时将Struts中的某个Action看作时客户端，其中doExecute(....)要调用doBusiness()这个方法

public void doAction(......)
{
 try
 {

  xxx.doBusiness();
 }
 catch(Exception e)
 {
   if(e instanceof RuntimeException) 
   {
    // catch runtime exception
    // 你可以在这里将捕获到的RuntimeException
    // 将异常通知给某个负责此程序的程序员，让他知道他
    // 自己犯了多么低级的错误！

   }else
   {
    //checked exception such as xxxBusinessException
    //将这样的异常暴露给客户显示    

   }

 }
}

我们可以这样设计xxxBusinessException

public class xxxBusinessException extends ApplicationException
{
    public xxxBusinessException(String s){
        super(s);

};

import java.io.PrintStream;
import java.io.PrintWriter;
public class ApplicationException extends Exception {
       /** A wrapped Throwable */
       protected Throwable cause;
       public ApplicationException() {
           super("Error occurred in application.");
       }
       public ApplicationException(String message)  {
           super(message);
       }
       public ApplicationException(String message, Throwable cause)  {
           super(message);
           this.cause = cause;
       }
       // Created to match the JDK 1.4 Throwable method.
       public Throwable initCause(Throwable cause)  {
           this.cause = cause;
           return cause;
       }
       public String getMessage() {
           // Get this exception's message.
           String msg = super.getMessage();
           Throwable parent = this;
           Throwable child;
           // Look for nested exceptions.
           while((child = getNestedException(parent)) != null) {
               // Get the child's message.
               String msg2 = child.getMessage();
               // If we found a message for the child exception,
               // we append it.
               if (msg2 != null) {
                   if (msg != null) {
                       msg += ": " + msg2;
                   } else {
                       msg = msg2;
                   }
               }
               // Any nested ApplicationException will append its own
               // children, so we need to break out of here.
               if (child instanceof ApplicationException) {
                   break;
               }
               parent = child;
           }
           // Return the completed message.
           return msg;
       }
       public void printStackTrace() {
           // Print the stack trace for this exception.
           super.printStackTrace();
           Throwable parent = this;
           Throwable child;
           // Print the stack trace for each nested exception.
           while((child = getNestedException(parent)) != null) {
               if (child != null) {
                   System.err.print("Caused by: ");
                   child.printStackTrace();
                   if (child instanceof ApplicationException) {
                       break;
                   }
                   parent = child;
               }
           }
       }
       public void printStackTrace(PrintStream s) {
           // Print the stack trace for this exception.
           super.printStackTrace(s);
           Throwable parent = this;
           Throwable child;
           // Print the stack trace for each nested exception.
           while((child = getNestedException(parent)) != null) {
               if (child != null) {
                   s.print("Caused by: ");
                   child.printStackTrace(s);
                   if (child instanceof ApplicationException) {
                       break;
                   }
                   parent = child;
               }
           }
       }
       public void printStackTrace(PrintWriter w) {
           // Print the stack trace for this exception.
           super.printStackTrace(w);
           Throwable parent = this;
           Throwable child;
           // Print the stack trace for each nested exception.
           while((child = getNestedException(parent)) != null) {
               if (child != null) {
                   w.print("Caused by: ");
                   child.printStackTrace(w);
                   if (child instanceof ApplicationException) {
                       break;
                   }
                   parent = child;
               }
           }
       }
       public Throwable getCause()  {
           return cause;
       }
}

而"聪明"的读者肯定要问我那doBusiness()这个业务方法该如何包装异常呢？

 public void doBusiness() throw xxxBusinessException
 {
   try
   {
     execute1(); // if it throw exception1

     exexute2(); // if it throw exception 2

     .... .....

   }
   catch (exception1 e1)
   {
    throw new xxxBusinessException(e1);
   }
   catch(exception2 e2)
   {
    throw new xxxBusinessException(e2);
   }
   ........
 }

 也可以这样

 public void doBusiness() throw xxxBusinessException
 {
   try
   {
     execute1(); // if it throw exception1

     exexute2(); // if it throw exception 2

     .... .....

   }
   catch (Exception e)
   {
    // 注意很多应用在这里根本不判断异常的类型而一股脑的采用
    // throw new xxxBusinessException(e);
    // 而这样带来的问题就是xxxBusinessException"吞掉了"RuntimeException
    // 从而将checked excption 与unchecked exception混在了一起！

    // 其实xxxBusinessException属于checked excpetion ，它根本不应该也不能够理睬RuntimeException
    if(! e instanceof RuntimeException) throw new xxxBusinessException(e);
   }
 }

总结
 1。JAVA的异常分为两类: checked exception & unchecked excpetion
 2。应用开发中产生的异常都应该集成自Exception 但都属于checked excpetion类型
 3。应用中的每一层在包装并传递异常的时候要过滤掉RuntimeException！
 4。从责任这个角度看Error属于JVM需要负担的责任;RuntimeException是程序应该负担的责任;checked exception 是具体应用负担的责任
 5。无论如何我们都不希望或者确切的说是不应该将RuntimeException这样的异常暴露给客户的，因为他们没有解决这个问题的责任！

今天讨论的不是不是内部类的概念，而是具体使用的一个场景－如何在内部类中返回外部对象

看一段代码

import java.util.LinkedList;
import java.util.List;

public class OuterClass
{

 private List listeners = new LinkedList();

 public void addListeners(IListener listener)
 {
  this.listeners.add(listener);
 }

 private OuterClass outer = this;  （1）
 private class InnterClass
 {
  public void publish()
  {
   //将事件发布出去 （2）
   for(int i=0;i < listeners.size();i++)
   {
    IListener listener = (IListener) listeners.get(i);
    listener.receiveEvent(outer);
   }
  }
 }

 public void execute()
 {
  InnterClass in = new InnterClass(); （3）
  in.publish();
 }
}

public interface IListener
{

public void receiveEvent(OuterClass obj);
}

你可能觉得这个例子很别扭，在哪里让你觉得难受呢？其实问题的关键就在于接口IListener的定义，这里需要给receiveEvent方法传递的参数是外部对象！（别激动，下面我会说明需要传递的一个场景）

场景

在一个GUI系统中，我们要在画板WorkSpace（WorkSpace实现了IListener接口）上产生一颗树，但树中的每个节点的产生（绘图）是我们不知道的算法，系统只为我们提供了一些绘图的接口，并返回元素的句柄！看来我们需要"包装"一下这个绘图的句柄Brush（其实我把它叫做笔刷，因为它只知道如何"刷"出图像来，就这点本事！）并对外提供节点Node这样一个通用的类。

此时Node与Brush的关系就很微妙了，不过我们可以抛开这些外表，看到Node与Brush其实就是外部类与内部类的关系！－第一步完成了：确定了两者的关系

然而，事情没有这么简单，Node类必须处理一些事件，而这些事件理所当然只有Brush能够看懂，而Node根本不知道这样的事件处理过程，现在有两个办法：办法一，让Node实现Brush所有的事件；办法二，把Brush返回回去，让它来处理自己的事件，看来办法二是个好主意，因为我可以不关心事件的种类！－第二步完成了：确定了事件处理的责任

还没完呢，你肯定不希望画板WorkSpace面对的是绘图的句柄Brush这样的对象，相反你只希望WokSpace只知道Node的存在！IListener接口中receiveEvent方法的参数定义为OuterClass 就由此而来！－第三步完成：接口的定义

public interface IListener
{

public void receiveEvent(OuterClass obj);
}

 既然说清楚了这个问题（应该比较清楚了吧？）那改如何实现这样一个蹩脚而有无可奈何的设计呢？让我们回忆一下内部类，内部类拥有访问外部类的方法与属性的权限

 private OuterClass outer = this;  － 这个对外部类的引用就是为内部类的访问准备的

 private class InnterClass
 {
  public void publish()
  {
   //将事件发布出去 

   for(int i=0;i < listeners.size();i++)
   {
    IListener listener = (IListener) listeners.get(i);
    listener.receiveEvent(outer);  － 这里不可以返回this，因为this代表的是内部类自己
   }
  }

参考

Java Nested class   http://blog.csdn.net/Killvin/archive/2006/01/10/574983.aspx

初识Java内部类    http://blog.csdn.net/killvin/archive/2006/01/10/574991.aspx