System Error with Catchall

System Error with Catchall

To enable error handling, BPL defines an element called <scope>. A scope is a wrapper for a set of activities. This scope may contain one or more activities, one or more fault handlers, and zero or more compensation handlers. The fault handlers are intended to catch any errors that activities within the <scope> produce. The fault handlers may invoke compensation handlers to compensate for those errors.

The following example provides a <scope> with a <faulthandlers> block that includes a <catchall>. Because the <scope> includes a <faulthandlers> element, the rectangle includes a horizontal dashed line across the middle; the area below this line displays the contents of the <faulthandlers>.

This BPL business process does the following:

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

2. The <scope> element starts the scope.

3. The second <trace> element generates the message before assign.

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

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

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

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

   

6. Within <catchall>, a <trace> element generates the message in catchall faulthandler.

7. Within <catchall>, another <trace> element generates a message that explores the nature of the error using $System.Status methods and the special variables %Context and %LastError. See the details in Event Log Entries.

8. The <scope> ends.

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

Event Log Entries

The corresponding Event Log entries look like this.

If an unexpected system error occurs, and a <faulthandlers> block is present inside a <scope>, the BPL business process does not automatically place entries in the Event Log as shown in the System Error with No Fault Handling example. Rather, the <faulthandlers> block determines what the business process will do. In the current example, it outputs a <trace> message that contains information about the error. The Event Log entry showing the actual error is produced by the following statement within the <catchall> block:

<trace value=
  '"%LastError "_
  $System.Status.GetErrorCodes(..%Context.%LastError)_
  " : "_
  $System.Status.GetOneStatusText(..%Context.%LastError)'
  />

The BPL context variable %LastError always contains a %StatusOpens in a new tab value. If the error was an unexpected system error such as <UNDEF> this %StatusOpens in a new tab value is created from the error “ObjectScript error” which has code 5002, and the text of the $ZERROR special variable. To get the corresponding error code and text out of %LastError, use the $System.Status methods GetErrorCodes and GetOneStatusText, then concatenate them into a <trace> string, as shown above.

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 scope"'/>
    <scope>
      <trace value='"before assign"'/>
      <assign property="SomeProperty" value="1/0"/>
      <trace value='"after assign"'/>
      <faulthandlers>
        <catchall>
          <trace value='"in catchall faulthandler"'/>
          <trace value=
            '"%LastError "_
            $System.Status.GetErrorCodes(..%Context.%LastError)_
            " : "_
            $System.Status.GetOneStatusText(..%Context.%LastError)'
            />
        </catchall>
      </faulthandlers>
    </scope>
    <trace value='"after scope"'/>
  </sequence>
</process>
}