Issue - 167 - Proposal for Vote

[Yuzo Fujishima <fujishima@bc.jp.nec.com>]

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