<throw>
Syntax
<scope>
<throw fault='"MyFault"'/>
...
<faulthandlers>
<catch fault='"MyFault"'>
...
</catch>
</faulthandlers>
</scope>
Details
| Attribute or Element | Description | Value |
|---|---|---|
| fault | Required. The name of the fault. It can be a literal text string or an expression to be evaluated. | A string of 0 to 255 characters. If this is an expression, it must use the scripting language specified by the containing <process> element. |
| name, disabled, xpos, ypos, xend, yend | See “Common Attributes and Elements.” | |
| <annotation> element |
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. This comparison is case-sensitive. When you specify a fault string it needs the extra set of quotes to contain it, as shown below:
<throw fault='"thrown"'/>
If there is a <catch> block that matches the fault, 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.
See Also
<catch>, <catchall>, <compensate>, <compensationhandlers>, <faulthandlers>, and <scope>.
