Business Process and Data Transformation Language Reference
<catchall>
[Back] [Next]
   
Server:docs2
Instance:LATEST
User:UnknownUser
 
-
Go to:
Search:    

Catch a fault or system error that does not match any <catch>.
Synopsis
<scope>
  <throw fault='"MyFault"'/>
        ...
  <faulthandlers>
    <catch fault='"MyFault"'>
          ...
    </catch>
    <catch fault='"OtherFault"'>
          ...
    </catch>
    <catchall>
          ...
    </catchall>
  </faulthandlers>
</scope>
Details
Attribute or Element Description
name, disabled, xpos, ypos, xend, yend attributes See Common Attributes and Elements.”
<annotation> element
Other elements Optional. <catchall> may contain zero or more of the following elements in any combination: <alert>, <assign>, <branch>, <break>, <call>, <code>, <compensate>, <continue>, <delay>, <empty>, <foreach>, <if>, <label>, <milestone>, <reply>, <rule>, <scope>, <sequence>, <sql>, <switch>, <sync>, <throw>, <trace>, <transform>, <until>, <while>, <xpath>, or <xslt>.
Description
When a <throw> statement executes, control immediately shifts to the <faulthandlers> block inside the same <scope>, skipping all intervening statements after the <throw>. Inside the <faulthandlers> block, the program attempts to find a <catch> block whose value attribute matches the fault string expression in the <throw> statement. If it finds one, the program executes the code within this <catch> block and then exits the <scope>. The program resumes execution at the next statement following the closing </scope> element.
If a fault is thrown, and the corresponding <faulthandlers> block contains no <catch> block that matches the fault string, control shifts from the <throw> statement to the <catchall> block inside <faulthandlers>. After executing the contents of the <catchall> block, the program exits the <scope>. The program resumes execution at the next statement following the closing </scope> element. It is good programming practice to ensure that there is always a <catchall> block inside every <faulthandlers> block, to ensure that the program catches any unanticipated errors.
For details, see BPL Error Handling Conventions in Developing BPL Processes.
Note:
If a <catchall> is provided, it must be the last statement in the <faulthandlers> block. All <catch> blocks must appear before <catchall>.
See Also
<catch>, <compensate>, <compensationhandlers>, <faulthandlers>, <scope>, and <throw>.