Re: [wsbpel] Q: Location of rethrow

[Frank Leymann <LEY1@de.ibm.com>]

+1

Although my argument for Yaron's second case would be:  FH1 caught x:foo
first place, otherwise FH2 would have been active at all. Thus, catching
x:foo again would get us into cyclic situations.

Regards,
Frank






Please respond to ygoland@bea.com

To:    Yuzo Fujishima <fujishima@bc.jp.nec.com>
cc:    wsbpel@lists.oasis-open.org
Subject:    Re: [wsbpel] Q: Location of rethrow


This is a create catch, all puns intended. Minimally Yuzo you should
file an issue on this in order to get a clarification into the spec.

I think the answer is that whenever a fault handler is entered one can
conceptually think of a state variable being associated with that fault
handler that records the current fault. When rethrow is called it is a
copy of the fault in the state variable that is rethrown.

So, using your original example:
    faulthandlers
       catch name="FH1" faultName="x:foo"
          sequence
             ...
             scope
                faulthandlers
                   catch name="FH2" faultName="x:foo"
                      ...
                rethrow

The rethrow would rethrow the fault caught by FH1 and it would be caught
by FH2.

My reasoning for this behavior is that rethrow was intended as a way to
allow programs to rethrow faults whose name and/or content they were not
aware of. So there is nothing 'magical' about rethrow, it just blindly
rethrows whatever fault is in 'scope'. In the example above the fault
that is 'in scope' is the one caught by FH1.

By contrast:

    faulthandlers
       catch name="FH1" faultName="x:foo"
          sequence
             ...
             scope
                faulthandlers
                   catch name="FH2" faultName="x:foo"
                      ...
                      rethrow
                ...

In the previous example the fault that will be rethrown is the one that
is caught by FH2. Note, however that the rethrown fault will NOT be
caught by FH1. The reason being that once a scope has thrown a fault and
a fault handler has caught it all of the scope's remaining fault
handlers are removed. Therefore the fault rethrown in the example above
would be caught by some unnamed parent scope.

                         Yaron


Yuzo Fujishima wrote:

>
>
> Hi,
>
> I have a question regarding where we can place <rethrow>.
>
> The current specification says:
>   <rethrow> activity can be used ONLY within a fault handler
>   (i.e. <catch> and <catchAll> elements).
>
> Therefore, I think the following is legal:
>   <faulthandlers>
>     <catch name="FH1" faultName="x:foo">
>       <sequence>
>         ...
>         <rethrow/>
>       </sequence>
>     </catch>
>   </faultHandlers>
>
> But I am not sure about the following:
>
>   <faulthandlers>
>     <catch name="FH1" faultName="x:foo">
>       <sequence>
>         ...
>         <scope>
>           <faulthandlers>
>             <catch name="FH2" faultName="x:foo">
>             ...
>             </catch>
>           </faultHandlers>
>           <rethrow/>
>         </scope>
>       </sequence>
>     </catch>
>   </faultHandlers>
>
> Q1: Is it legal to place the <rethrow> there?
>
> Q2: Assuming the answer to Q1 is yes,
>     will FH2 catch the rethrown fault?
>
> Yuzo Fujishima
> NEC Corporation
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
>
>
>  From - Fri

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.