我对Java的异常处理机制的理解

   首先从一个问题引出一个角度：跑java程序的机器在如何运行？

   Jvm 和物理机器构成了一个运行环境。这个运行环境“吸收”提供的class文件或其他资源，包括java main入口的给定参数等等，以多线程thread形式运行着。线程在另一个线程中诞生出来，某一天魂归西天。在线程诞生之初就属于一个分组threadgroup。

   然后描述另外一个角度：所谓运行环境吸收的材料中，比如class文件，其实是我们程序员给的运行规定。就是说我们按java language specification给出了我们对如何运行的命令信息。实际运行和我们的意愿之间到底是怎么相关呢？

运行环境的出现之初就会按我们的意愿试图执行某个类的main.首先运行环境会诞生一个主线程，这个主线程首先要求运行环境已经initializing这个类，没有就得initializing这个类，在做initializing之前又得要求linking,以致loading,不管怎么样，这样的约定导致主线程会运行loading，linking,initializing，然后再运行main方法里我们表达的意思。当然在这个主线程里也会按我们的意思诞生新线程，这个新线程也还是得在诞生之初按我们的意愿试图执行那个runable类的run方法，这当然也得要求initializing。所不同的是有可能这个initializing在某个其他线程里给运行了，那么也就是说运行时环境满足了这个要求，那在当前线程中就不干这个事了。

   最后我们来看异常的概念。

   显然我们的意愿是不容违背的。呵呵。可是现实归现实，总有那么多不尽人意。当运行时环境参照我们的意愿以各个线程运行时，总可能出现点违背意愿的事，也就是异常。这个情况的出现可能是机器内存条抖了下，可能是我们的意愿就不正常，比如想数组越界访问，或者我们的意愿就是“请此刻马上当作异常发生了”等等。那么这时会怎么运行呢？

   这种情况当然是在线程中发生的，发生后运行时大师就会根据当前情况构造一throwable实例，然后寻找本线程要转到哪个点上去继续运行。这到底是哪个点，这个意愿当然还得我们程序员通过java language specification给出命令信息。我们的意愿不一定非要写出来，有一个是约定好的：异常传播跳出前释放同步块的锁。那么如果运行时大师找到了这个点，就会安排本线程继续从这个点运行，找不到，那么运行时大师就会把该线程杀了。杀之前先执行它的threadgroup的uncaughtException方法里我们表达的意愿。注意不管是在那个点还是这个方法，我们都有机会表达对那个throwable实例怎么怎么样的想法。

   Ok, 现在基本框架已经有了，再具体的描述下。

   刚才说到了每个线程的运行，异常是有很多种情况的。那这种情况算什么时候发生的呢？总起来说就是什么时候触发了执行，什么时候算。比如我们有一句a=1/b.当线程参照这句执行时，发现b=0,那就可以说在这时发生了个异常。再比如我们某StringUtils.contact(s1,s2);当线程参照这句执行时，可能就会要求先做StringUtils的resolving（linking的最后一个可选步骤）,但也可能在线程link该句所属的类时就会做，这根据jvm规范得看jvm怎么实现了。但不管怎么说，什么时候做的resolving，而在这个过程中出异常了，就得算这个点。这样就有一个意识：发生点是可以嵌套的。比如a方法a步调用b方法，但b里b步抛异常了，我们可以说b步是个点，但对a来说，a步也是这个点。最原始的那个点怎么算？怎么说都无所谓。但有谓的是下面：

   运行时大师就会根据当前情况构造一个throwable实例！其中当前情况就有一个当前线程的执行栈信息。这个当前信息怎么算有所谓。而且，然后寻找线程要转到哪个点上去继续运行。从哪里开始找起也有所谓。这两个所谓都在jvm中规范了。

   关键是我们程序员如何表达。

•    1 当前信息就是线程当时的栈信息。注意这个栈信息是我们的程序（包括Lib）的某个方法名的一些信息，而不是细化到某个操作2进制指令。

•    2 从哪里找起？

   我们的程序中哪句是最终导致异常的，从这一句所在的代码块开始找起。所以主线程一开始时initialize那个main类，如果jvm实现是最早link，那么可能会由此递归initialize很多main类应用的类，如果这个过程中出异常了，我们甚至就没有必要找了，之后怎么处理无所谓；如果initialize后执行main方法过程中某句导致出异常了，那就得从这一句所在的代码块开始找起。Try{ ~~~;a;~~~;}catch{}finally{} 。Catch不匹配就要跳出这个try块，但跳出之前也要先让本线程运行完finally。如果catch,finally又抛异常了，那就形成一个新异常，原来的异常的信息不见了，所以要小心。注意“那个最终导致异常的那一句”是这个意思，比如Try{~~~;a（）;~~~;}catch{}finally{}。a()出异常了，但不是a()句，而是a()方法中出异常的最终那一句，由此递归到程序可见的最终一句。从那个地方找起。

异常多数是同步发生的，就是在线程的某个固定环节发生，但也有异步的，比如内存溢出，谁也不知道会在哪个线程中哪个点发生，对于这样的异步异常，jvm规范中说jvm实现让这种异常实际发生后代码继续运行一有限段，所以给出一个简单实现模型：运行时对这种异常的检测时每次线程做控制转移指令时，比如条件转移啊等等。

   但是无论什么异常，对于我们用java表达的意愿，必须满足：异常逻辑发生时之前的java都执行了，之后的都没有执行。至于实际实现中，可能我们看到的异常发生时刻和实际的发生时刻有差别（因为运行时检测不是实时的），也可能我们看到的代码执行和编译器优化后实际的执行顺序不一致，但不管怎么样，我们看到的和表达的必须一致。

   最后看异常的分类。我截至目前说的异常都是一个广义的概念，实际上应该对应throwable这个类。Throwable之下有exception和error.exception下有很多，其中有一个是RuntimeException。我们用他们表达对运行的意愿，同时我们也用他们表达我们对提供的接口运行时可能出现的异常的提示。这种表达是java的特色，一般语言不会直接表达这种可能性。假如说我们的某个方法可能抛exception，意思是别人使用这个方法时能处理这个异常，对非runtimeexception一定要么捕捉下，要么继续传播；对runtimeexception,可以不做处理。而假如说我们的某个方法可能抛error，意思则是别人用这个方法可能会面对error,而且不认为别人能处理。从另一个方面，对于我们使用某个方法，如果他声明会抛一个非runtimeexception，我们必须处理，真有error的可能我们都不用，当然也可能记下日志就算了。考虑到这种含义，编译器帮助我们一定要处理非runtimeexception。

现在，很多所谓的协同工作流实现都出现了理解歪曲。对此，我将描述一种新的工作流概念的理解，然后基于其上，对xpdl做一个改造，形成新的工作流的描述语言。

我们做software,常常自然地关注功能概念，即写码+硬件组成一种可用的功能，比如我们常说给用户编出一个查询存货列表的功能，再加一个菜单；我们常常单纯基于这种功能概念构造系统。所谓对功能“搭积木”模式更加体现了这种概念。从深层次讲，这满足了一种静态观察的需求；而随着用户水平的提高，他们逐渐能够表达一种基于动态观察的需求。典型地说，管理者希望确保某个产品从进货到出货的整个过程都是最有效率的。继而，整个企业需要整个企业的运作中每个环节都是最正确有效的。对于企业而言，企业的每一个变化，活动，最好都是实现企业目标的最有效，最正确的一步。企业的需要，就是帮助他们实现企业，这个系统，一直以正确的活动序列向着企业目标运行着。目前用户还没有完全能把这种需求表达确切，现在所谓“协同”等概念其实就是对这种需求的模糊的表达。下面我试着表达解决这种需求的模型思路。

人如何实现目标？人类有一个一般的解决途径---控制系统的变化。比如我们追求自己的某个目标，往往先做一个计划，然后依照计划不断实现，反馈，修改计划。计划本质上就是对变化的控制。我们的思维中很重要的很基本的一条，就是从目标出发，分析出达到目标的途径。之后我们按途径进行受控活动。比如我们想解决温饱，最终就会分析到占有土地，提高种子质量等，然后我们会控制自己或员工去一步步做这些事。

企业的每一个具体活动如果都是某个定义好的流程实例的环节实例(都是计划的一部分)，那么所有的活动就可以完全受控。受控就意味着可以进行优化，监控等，所以能控制到所有活动基本就成为实现最终需求的基础。

   控制的粒度需要非常灵活。我们允许用户去定义提交一个存货单就是一个环节，也可以包括更多的内容在这个环节中。不同的企业规模，即使同一个业务流程，肯定对控制粒度要求也不同。所以保证这种灵活性非常重要。

   流程就是活动的阶段性集合。比如全局就是一个流程，就是说企业的整个运作就是一个流程。之后比如什么请假流程都只是其中的一部分。而活动是一个黑盒，不可再分，它的划分涉及到粒度的把握。定义一个流程，实际是需要规范一系列活动。随着流程种类的不断开发，整个企业的运作就会日益受到控制。随着粒度的分合，运作的管理更加细致科学。而且随着整个社会的进步，活动系列也会相应调整，流程定义也要不断更新。所以要保证流程定义的易操作。这个多采用图形化定义解决。

   流程的定义本身是一个控制活动的直接手段。通过借助观察大量流程实例的数据，可以进行统计分析，反过来改善流程定义。再加上对一个流程实例本身可以做暂停等管理，从而实现对整个企业活动的长期规划，即时调整，最终满足企业的需求，控制住企业的良好运作。

   这是基于这种需求的理解，这种解决思路，使得这个模型非常不同。

   1 流程定义。现在的流程定义，都出现了参与者等信息，而且还出现了如何运作的信息 --- 关联某个应用功能模块。这些我认为都是一种歪曲。实际上这样做就将另一层次的需求混杂了进来。那就是通用的功能模块。比如某人在某环节可以填某个表的某些字段。这个出现在流程定义中，混淆了流程定义的本义。我认为流程定义本身仅仅是活动的划分。至于这个活动谁来完成，如何完成，根本不属于流程定义的范畴。定义一个流程，是对全局流程的某系列活动的一个划分，描述信息就是做什么的或者说达到什么目标的，本质是划分依据。每一个元素就是一个活动。这个活动的信息可能没办法明确出什么目标，但是基本上也是一个划分依据的描述。

   但是我们描述流程的时候，往往习惯有一个流的概念。即 A 结束后是 B 。实际上这种信息根本无法静态描述。这一点和前面说的混淆，这两点导致实现非常不顺畅，高度太低的原因尔。

2 反过来说这两点，以另外的方式处理。表的字段访问控制作为一个通用功能单元即可，参与者放到权限控制模型中去实现。对于 transition ，由活动环节本身在结束时指定下一个。而如何指定，提供一个根据默认定义指定的通用功能。而这默认指定，则可以在流程定义中给出。虽然形式上仍然是元素间连线，但意义不同，这样我们不把这种 transition 信息作为流程定义的必需组成。

3worklist 。实现这样一个功能单位，让用户自己去一个列表中领取进行中的环节即可，某个用户判断可以结束了，直接声明结束环节。这是最简单直接的实现。不用担心权限问题，因为即使领取了环节，也不一定有功能权限去做实际功能。当然为了方便用户，可以做一个功能单位，让不同用户看到可以做的环节。

4 管理。其实就是那些暂停，看流程实例状态等。以新的理解，那其实这些也是某环节活动的组成部分。像原来一样做。当某个流程暂停了，那么系统就不会允许下一个环节的诞生。

5 至于所谓业务数据流，其实对于某一个功能，如果当初设计的是环节相关的，那他就可以通过领取的环节取到环节 id, 流程 id, 这些就足够了。如果不是环节相关的，比如某人的基本信息录入，那可能根本用不到这些数据。显然，一个环节可能是需要使用多个功能，这也和以前的理解不同。实际上我是这样做对，一个用户开始进入系统，默认持有系统流程大环节 id, 然后在列表中选择一个环节来参与进去，那就在会话中一直持有该环节。这体现了用户 A 正在受理某业务环节中的现实表现。

探索中，欢迎交流！msn:sun_v2006@hotmail.com