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):
-
The first <trace> element generates the message before outer scope.
-
The first <scope> element starts the outer scope.
-
The second <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> 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:
-
Within this <catchall>, the <trace> element generates the message in inner scope, catchall.
-
The inner <scope> ends.
-
The next <trace> element generates the message in outer scope, after inner scope.
-
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.
-
The outer <scope> ends.
-
The last <trace> element generates the message after outer scope.