Skip to main content

Nested Scopes, Inner Fault Handler Has Catchall

Nested Scopes, Inner Fault Handler Has Catchall

It is possible to nest <scope> elements. An error or fault that occurs within the inner scope may be caught within the inner scope, or the inner scope may ignore the error and allow it to be caught by the <faulthandlers> block in the outer scope. The next several topics illustrate how BPL handles errors and faults that occur within an inner scope, when two or more scopes are nested.

Suppose you have the following BPL (shown here without the <start> and <end> elements):

Complex BPL diagram with nested scope shapes, resulting in nested rectangles

This BPL business process does the following:

  1. The first <trace> element generates the message before outer scope.

  2. The first <scope> element starts the outer scope.

  3. The second <trace> element generates the message in outer scope, before inner scope.

  4. The second <scope> element starts the inner scope.

  5. The next <trace> element generates the message in inner scope, before assign.

  6. The <assign> element tries to evaluate the expression 1/0. This attempt produces a divide-by-zero system error.

  7. Control now goes to the <faulthandlers> defined within the inner <scope>. This <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, there is no <catch> but there is a <catchall>, so control goes there.

    Note that InterSystems IRIS skips the <trace> element immediately after the <assign> element.

    If we drill into this <catchall>, we see this:

    BPL diagram with the following shapes in order: start, trace, end

  8. Within this <catchall>, the <trace> element generates the message in inner scope, catchall.

  9. The inner <scope> ends.

  10. The next <trace> element generates the message in outer scope, after inner scope.

  11. The outer <scope> rectangle includes a horizontal dashed line across the middle; the area below this dashed line displays the contents of the <faulthandlers> element that contains a <catchall>. Because there is no fault, this <catchall> is ignored.

  12. The outer <scope> ends.

  13. The last <trace> element generates the message after outer scope.

Event Log Entries

The corresponding Event Log entries look like this:

Event log showing that nested scopes are identified with the terms inner scope and outer scope

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>
          <catchall>
            <trace value='"in inner scope, catchall"'/>
          </catchall>
        </faulthandlers>
      </scope>
      <trace value='"in outer scope, after inner scope"'/>
      <faulthandlers>
        <catchall>
          <trace value='"in outer scope, catchall"'/>
        </catchall>
      </faulthandlers>
    </scope>
    <trace value='"after outer scope"'/>
  </sequence>
</process>
}
FeedbackOpens in a new tab