OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] fault handling



Yes, it helps, thanks.

Are there other effects when a scope fails? (other than the fact that it
can't be compensated)

alex

Satish Thatte wrote:
> Ah, I see the confusion.  You can do exactly this kind of fault
> *suppression* in BPEL.  However, the scope that completes thus is not
> successful in spite of the fact that it did not propagate the fault.
>
> In the coordination protocol in Appendix C, this is modeled by an
> "exited" as opposed to "completed" signal to the enclosing scope.  The
> main distinction is that an exited scope cannot be compensated.
>
> Does that help?
>
> Satish
>
> -----Original Message-----
> From: Alex Boisvert [mailto:boisvert@intalio.com]
> Sent: Monday, May 26, 2003 7:52 AM
> To: Satish Thatte
> Cc: [unknown]
> Subject: Re: [wsbpel] fault handling
>
>
> Satish,
>
> I understand the current exception processing semantic but for my own
> edification (and probably the list's), I would appreciate your
> explanation on the rational behind the decision to have faults always
> cause scopes to fail.
>
> I am used to the model where you can handle a fault and decide whether
> or not the fault is propagated to a higher-level context.
>
> Example (in Java):
>
> try {
>      // normal processing
> } catch ( Exception fault ) {
>      // decide to continue or propagate fault
>      if ( condition ) {
>          // handle exception
>      } else {
>         throw fault;
>      }
> }
>
> regards,
> alex
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]