← Prev in month ← Prev in thread
Next in thread → Next in month →

Issue - R22 - <rethrow> of Fault Name and Fault Data Where Present

From
ws-bpel issues list editor <>
Date
2006-10-17T23:13:54+00:00
ID
Thread
Issue - R22 - <rethrow> of Fault Name and Fault Data Where Present
This issue has been added to the wsbpel issue list with a status of "received".
The status will be changed to "open" if a motion to open the issue is proposed and that
motion is approved by the TC. A motion could also be proposed to close it without
further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the 
OASIS WSBPEL TC pages
on a regular basis. The current edition, as a TC document, is the most recent version of 
the document entitled  in the 
"Issues" folder of the WSBPEL TC document list
- the next posting as a TC document will include this issue.
The list editor's working copy, which will normally include an issue when it is announced, is available at 
this constant URL.

Issue - R22 - <rethrow> of Fault Name and Fault Data Where Present
Status: received

Date added: 17 Oct 2006

Date submitted: 16 October 2006

Submitter: Monica J. Martin

Description: The semantics of <rethrow> are quite 
specific about fault data but no explicit mention is made about the 
fault name of the original fault where present.  No references are found 
in Section 5, 10 or 12 where <rethrow> is addressed. Therefore, a minor 
editorial revision is suggested in Section 10.1 (i.e. in first sentence).

Submitter's proposal: Change from:

The <rethrow> activity is used in fault handlers to rethrow
the fault they caught. It can be used only within a fault
handler (<catch> and <catchAll>). Modifications to the fault
data MUST be ignored by <rethrow>. For example, if the logic
in a fault handler modifies the fault data and then call
<rethrow>, the original fault data would be rethrown and not
the modified fault data. Similarly if a fault is caught
using the shortcut that allows message type faults with one
part defined using an element to be caught by fault handlers
looking for the same element type, then a <rethrow> would
rethrow the original message type data (see section 12.5.
Fault Handlers).

to:

The <rethrow> activity is used in fault handlers to rethrow
the fault they caught, i.e. the fault name and fault data of
the original fault where present. It can be used only within
a fault handler (<catch> and <catchAll>). Modifications to
the fault data MUST be ignored by <rethrow>. For example, if
the logic in a fault handler modifies the fault data and
then call <rethrow>, the original fault data would be
rethrown and not the modified fault data. Similarly if a
fault is caught using the shortcut that allows message type
faults with one part defined using an element to be caught
by fault handlers looking for the same element type, then a
<rethrow> would rethrow the original message type data (see
section 12.5. Fault Handlers).

Changes: 17 Oct 2006 - new issue

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the 
 list (replying to this message should automatically send your message to that list), or ensure
the subject line as you send it starts "Issue - R22 - [anything]" or is a reply
to such a message. If you want to formally propose a resolution to an open issue, please start the subject line 
"Issue - R22 - Proposed resolution", without any Re: or similar.

To add a new issue, 
see the issues procedures document
← Prev in month ← Prev in thread
Next in thread → Next in month →