[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 167 - Proposal for Vote
Hi, I would like to propose to vote on a resolution for issue 167. The proposed resolution is the same as the submitter's proposal in spirit but modified to hopefully be more understandable: Proposed resolution: Consider a <rethrow> as a macro for a <throw> that throws the fault caught by the corresponding fault handler. A fault handler is said to be corresponding to a <rethrow> if the handler encloses the <rethrow> without intervening fault handlers. Yuzo Fujishima NEC Corporation ws-bpel issues list editor wrote: > This issue has been added to the wsbpel issue list with a status of "received". > The status will be changed to "open" if the TC accepts it as identifying a bug > in the spec or decides it should be accepted specially. Otherwise it will be > closed without further consideration (but will be marked as "Revisitable") > > The issues list is posted as a Technical Committee document to the OASIS WSBPEL > TC pages <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular > basis. The current edition, as a TC document, is the most recent version of the > document entitled ** in the "Issues" folder of the WSBPEL TC document list > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - the next > posting as a TC document will include this issue. The list editor's working > copy, which will normally include an issue when it is announced, is available at > this constant URL <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > > > Issue - 167 - Rethrow semantics clarification > > *Status:* received > *Date added:* 4 Oct 2004 > *Categories:* Syntax and validation <#category_syntax_and_validation> > *Date submitted:* 04 October 2004 > *Submitter:* Yuzo Fujishima <mailto:fujishima@bc.jp.nec.com> > *Document:* WSBPEL Working Draft, September 8, 2004 > *Description:* > > The current specification needs clarification on the behavior of the rethrow > activity. > > For example, it is unclear that a rethrown fault can be caught by a fault > handler defined inside the fault handler that has caught the fault. > > Suppose we have the following process definition snippet: > > <faulthandlers> > <catch name="FH1" faultName="x:foo"> > <sequence> > ... > <scope> > <faulthandlers> > <catch name="FH2" faultName="x:foo"> > ... > </catch> > </faultHandlers> > <rethrow/> > </scope> > </sequence> > </catch> > </faultHandlers> > > Will FH2 catch the rethrown fault? > > Champion: Yuzo Fujishima <fujishima@bc.jp.nec.com> > *Submitter's proposal:* > > Consider rethrow as a throw with a faultVariable attribute that specifies the > implicit fault variable associated with the fault handler. > > Therefore, the answer to the question above is: Yes, FH2 will catch the fault. > > In addition, it should be noted that a rethrow is associated with the innermost > enclosing fault handler. > *Changes:* 4 Oct 2004 - new issue > > -------------------------------------------------------------------------------- > > To comment on this issue (including whether it should be accepted), please > follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying > to this message should automatically send your message to that list), or ensure > the subject line as you send it *starts* "Issue - 167 - [anything]" or is a > reply to such a message. If you want to formally propose a resolution to an open > issue, please start the subject line "Issue - 167 - Proposed resolution", > without any Re: or similar. > > To add a new issue, see the issues procedures document (but the address for new > issue submission is the sender of this announcement). > > > Choreology Anti virus scan completed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]