Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.

For information on migrating to InterSystems IRIS, see How to Migrate to InterSystems IRIS, available on the WRC Distributions page (login required).


Catch a fault produced by a <throw> element.


   <throw fault='"MyFault"'/>
      <catch fault='"MyFault"'>


Attribute or Element Description Value
fault attribute 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 attribute See “Common Attributes and Elements.”  
<annotation> element
Other elements Optional. <catch> 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>.  


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:

<catch 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.


If a <catchall> is provided, it must be the last statement in the <faulthandlers> block. All <catch> blocks must appear before <catchall>.

See Also

<catchall>, <compensate>, <compensationhandlers>, <faulthandlers>, <scope>, and <throw>.