ProcScript Call Stack
When script modules are called or activated at runtime, the call is added to the ProcScript call stack, along with their associated component names and line numbers. The most recent module appears at the top of the call stack.
When a module is called recursively, a level of ProcScript nesting is added to the call stack. Too many levels of nesting cause Uniface to issue a fatal error message:
9033 "Runtime error: Proc stack overflow"
The maximum number of levels depends on the type of script module. Entries can have a larger call stack than operations.
The call stack becomes more visible when exception handling is enabled. If an exception occurs, the call stack will return details of the line where the error occurred and the code that called it. This can help you identify where to add try-catch blocks to handle exceptions.
Viewing the Call Stack
You can view the call stack using the Debugger. If your code is exception-enabled, you can also see it in the CALLSTACK item of $procerrorcontext or, for Windows and character-based components, in the form that is displayed when an uncaught exception occurs.
Exception Handling
The call stack makes the current code execution state visible, which is particularly useful when exception handling is enabled. When an exception occurs, the ProcScript module executing the code that caused the exception appears at the top of the call stack. If the exception is not caught and bubbles up, the call stack unwinds to the ProcScript module that contains the try-catch block.
Special Considerations
For user interactions, the call stack may not always appear obvious. Interactive triggers in modal and non-modal forms are invoked by the runtime structure editor in idle state. In a modal form, the edit statement starts the idle mode, and is therefore considered the call stack parent. In a non-modal form, the apstart statement in the parent application shell is the call stack parent of idle mode. To catch exceptions that bubble up from these forms, place a try-catch block around the edit statement in modal forms, and the apstart statement for non-modal forms.
Note: If apstart is omitted, Uniface behaves as if it is implicit; however, this implicit apstart is not visible in the call stack. In order to catch an exception here, you need to explicitly add the apstart statement and place it in a try-catch block.
In web applications, the webget statement is the parent of all triggers of a Static Server Page (USP) component, while the activate statement is the parent of all Dynamic Server Page (DSP) triggers. Many exceptions bubble through these statements. To handle them, place the try-catch block around the appropriate calling code for your web application type.
