This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
> ****WILL BE HANDLED BY BANANAS**** > > Section 3.5 > 1) Monica. Interactions and exceptions: If the exception handling is > not defined, the potential state changes cannot be fully described > either. > David. Agreed, if exceptions are not defined and something goes wrong > then the behavior of the choreography is undefined./ > 2) Monica. If exceptions are handled within the context of a work unit > (of activities), how does this in effect realize itself in the > interactions > associated with the portable choreography - one-way and req-response? > David. Exceptions are handled at the Choreography level rather than > within a workunit. Not sure what you mean about your last point. > 3) Monica. These may or may not be the same (and may impact one > another). Exception conditions can occur that may be supported, at a more > granular level, with error handling at the message level. > David. I definitely think that exception conditions can be many and > varied in the levels they could cover, e.g. security/message errors, > choreography sequence errors, data errors, etc. All of these could > affect the flow of the choreography. > Section 3.7: > 4) Monica. (BUSINESS SEMANTIC) > Exception != Error (BUS SEMANTIC != MESSAGE OCCURRENCE) > David. If I understand you correctly, you are saying that an exception > is not the same as an error as you might have a "business exception" > that appears as a normal interaction (i.e. a message) in the > choreography. I agree. However, I do think that exceptions are really > in the mind > of the choreography designer. For example you COULD define all the > work units in the Base Choreography whether they are "normal" > (whatever that means) or "exceptions" (again whatever THAT means!). > The reason for having an exception block was to make the > choreography easier to understand as you then had one section (the > base choreo block) that defines what usually happens, and another (the > exception block) that defines what's unusual. The actual split is > arbitrary. > All above: mm2: This is a broader discussion, I think. Because I am > still toying with the bananas and where they get peeled. Given this > set of comments, I am leaning to the fact that the exceptions are > understood at the business semantic level and only seen as another > message in WS-CDL.
> Monica. Interactions and exceptions: Relates to previous questions > about mixing levels of functionality and concepts. > David. Don't completely understand your point. > mm2: Issue I-01 indicates the interactions do not describe how errors > are handled. I think if we can nail down IF exceptions are handled by > CDL then we can discuss what errors occur when an exception takes > place. Understand, the idea of an exception may very well be outside > of CDL, although that does not mean that an error occurs that CDL > handles. > Thanks.
Discussion of "Banana Calculus": http://lists.w3.org/Archives/Public/public-ws-chor/2004Mar/att-0005/Bananas.htm
This issue is not clear to us, request clarification within the context of the apr 3 cdl spec from orignator (monica).
clarification from Monica: We have addressed this in our discussion on exceptions (banana calculus) and exception propagation (from August F2F and the proposal on state alignment). I do not know if an explicit issue exists for exception propagation.
exception propagation feature is required
*** Bug 686 has been marked as a duplicate of this bug. ***
Proposal: http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0026.html
Proposal: http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0013.html
Proposed modification to http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0026.html http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0063.html