RE: [wsbpel] fault handling

["Satish Thatte" <satisht@microsoft.com>]

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

Satish Thatte wrote:
> Could you be a bit more specific (about exceptions not camels)?  Which
> aspects of exception processing would you like clarification on?
> 
> One especially troublesome area I am aware of is the stipulation that
a
> fault in a scope always dooms the scope to unsuccessful completion.  A
> lot of people (including a bunch of the authors at various points)
have
> tried to make fault handlers act as "alternative completion paths" but
> this has always caused far more problems than it solved.  If that's
the
> sort of thing you mean, I can take a shot at giving my version of the
> explanation for the current design.
> 
> Satish
>