Nested Scopes, No Match in Either Scope

Suppose you have the following BPL (partially shown):

The rest of this BPL is as follows:

Partial BPL diagram with the following elements in order: trace, catch, join, trace, end

This BPL business process does the following:

The first <trace> element generates the message before outer scope.
The first <scope> element starts the outer scope.
The next <trace> element generates the message in outer scope, before inner scope.
The second <scope> element starts the inner scope.
The next <trace> element generates the message in inner scope, before assign.
The <assign> element tries to evaluate the expression 1/0. This attempt produces a divide-by-zero system error.
Control now goes to the <faulthandlers> block in the inner <scope>. The <scope> rectangle includes a horizontal dashed line across the middle; the area below this dashed line displays the contents of the <faulthandlers> element. In this case, a <catch> exists, but its fault value does not match the thrown fault. There is no <catchall> in the inner scope.
Control now goes to the <faulthandlers> block in the outer <scope>. No <catch> matches the fault, and there is no <catchall> block.
The BPL immediately stops, sending a message to the Event Log.

Event Log Entries

The corresponding Event Log entries look like this.

Event log with error after inner scope and before assign elements

There is an important difference between this Event Log and the one in the System Error with No Fault Handling example. The two examples have this in common: Each fails to provide adequate fault handling for the case when the divide-by-zero error occurs.

The difference is that the System Error with No Fault Handling example has no <scope> and no <faulthandlers> block. Under these circumstances, InterSystems IRIS automatically outputs the system error to the Event Log, as shown in the first example.

The current example is different because each <scope> does include a <faulthandlers> block. Under these circumstances, InterSystems IRIS does not automatically output the system error to the Event Log, as it did in the System Error with No Fault Handling example. It is up to the BPL business process developer to decide to output <trace> messages to the Event Log in case of an unexpected error. In the current example, no <faulthandlers> block catches the fault, so the only information that is traced regarding the system error is contained in the automatic message about business process termination (item 4 above).

The system error message does appear in the ObjectScript shell:

ERROR #5002: ObjectScript error: <DIVIDE>zS4+3^Test.Scope.BusinessProcess.Thread1.1

XData for This BPL

This BPL is defined by the following XData block:

XData BPL
{
<process language='objectscript'
         request='Test.Scope.Request'
         response='Test.Scope.Response' >
  <sequence>
    <trace value='"before outer scope"'/>
    <scope>
      <trace value='"in outer scope, before inner scope"'/>
      <scope>
        <trace value='"in inner scope, before assign"'/>
        <assign property="SomeProperty" value="1/0"/>
        <trace value='"in inner scope,after assign"'/>
        <faulthandlers>
          <catch fault='"MismatchedFault"'>
            <trace value=
              '"In catch faulthandler for &apos;MismatchedFault&apos;"'/>
          </catch>
        </faulthandlers>
      </scope>
      <trace value='"in outer scope, after inner scope"'/>
      <faulthandlers>
        <catch fault='"MismatchedFault"'>
          <trace value=
            '"In catch faulthandler for &apos;MismatchedFault&apos;"'/>
        </catch>
      </faulthandlers>
    </scope>
    <trace value='"after outer scope"'/>
  </sequence>
</process>
}

Nested Scopes, Outer Fault Handler Has Catch

Nested Scopes, Outer Fault Handler Has Catchall