[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:[email protected]]
> 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]