知识点内容：

　　数据库操作构建包fcdatabase相关构件可以使用异常线捕获异常，但工作流相关构件不能使用异常线捕获异常，必须使用返回值形式判断是否执行成功，其他构件异常处理方式请仔细查阅帮助后方可确定。
 
　　遇到的问题：

　　之前农行资金交易系统出现迭代中事务间断的不能正常提交的现象，具体表现为第一次执行页面报执行失败，返回重新执行又成功了，有时第二次执行也失败多点几次又成功了，花了较多时间没有找到原因，甚至还请来了陈路凝、杨飞一起解决，起初怀疑是Tomcat对事务支持不完善引起的，并花费了较多的时间将所有人的服务器切换到JBOSS，切换到JBOSS以后唯一的好处是迭代中如果前面的事务提交出现异常后面的事务也不会提交，而Tomcat中后面的事务还会正常提交。

　　但后来仔细研究却发现真正的原因是BL_startProcessInstance和BL_finishWorkItem执行失败时使用异常线没有成功捕获引起的，因为工作流相关的构件没有抛出异常，后来让全体开发人员将自己的代码全部搜索一遍，只要是工作流相关的构件都将异常线去掉，改成判断返回值的方式得以解决，浪费了很多时间不说，还给客户方留下不好的印象。
 
　　两种异常处理方式的比较：

　　1. EOS构件库中大家最常用的数据库操作构建包fcdatabase，其下的构件全都没有处理异常，而是直接将异常抛出，为了保证功能的完整性以及出错提示的可控性，所以大家在设计业务逻辑时必须使用异常线来捕获数据库端可能抛出的DataBaseException和DataServiceException等，可能也正是这个原因使大家认为只要是数据库操作都需要使用异常线捕获异常；

　　以BL_updateEntity为例，其返回值和抛出异常说明如下

　　1)返回值说明

　　2)抛出异常说明

　　a.传入的参数节点类型错误时抛出异常java.lang.ClasscastException。   //这种异常属于设计上的问题，应该在开发期就解决

　　b. 输入的EOSEntity数据中没有主键或者更新数据库失败时抛出异常com.primeton.tp.core.api.DataServiceException。 //这种异常必须使用异常线捕获
 
　　2. 而同样属于数据库操作的工作流构件库，其下的构件却全都捕获了异常，这样一来使用异常线便起不到任何作用，而必须使用返回值的方式来处理各种异常情况，当然我们的规范中是要求构件本身不抛出异常。

　　以BL_startProcessInstance为例，其返回值和抛出异常说明如下

　　1)返回值说明

　　如果要让我们这个团队成为国际一流的团队，让我们的产品成为国际顶尖的产品，需要我们中的每一个人在每一个阶段，每一个环节做每一件事都力求完美，一丝不苟的切实执行，这样才能做出世界上最好的产品，才能提供最好的服务，才能拥有最强的竞争力。

　　说明：非成功操作的具体的出错信息可通过BL_getLastErrorMessage获取。

　　4)抛出异常说明

　　无    //没有任何异常抛出，自然不能使用异常线捕获，必须使用返回值判断操作是否成功。
 
　　问题反思：

　　1.我对EOS构件的理解还有不足之处，将来还要在细节上更加注意。

　　2.从构件本身角度考虑，两种构件的返回值及抛出异常情况存在较大差异，这难免会给开发人员增加难度，是不是每调一个构件都要先仔细研读它的帮助文档呢？从另一个角度考虑，我们的构件似乎没有严格按照统一的规范编写，至少还不够完美，这其中还有较大的优化空间。

　　原文出处：http://gocom.primeton.com/modules/newbb/item54075_54075.htm