How to log the line number of code that raises an error when using structured error handling

How to log the line number of code that raises an error when the error is trapped using a CATCH block or "ROUTINE-LEVEL ON ERROR UNDO, THROW"

Aug 19, 2014
Knowledge

Title

URL Name

000052857

Article Number

000170166

Environment

Product: OpenEdge Version: 10.1C, 10.2x, 11.x OS: All supported platforms

Question/Problem Description

How to log the line number of code that raises an error when using structured error handling

How to write the line number of code that raises an error to the client log when the error is handled in a CATCH block

How to write the line number of code that raises an error to the client log when the error is handled using ROUTINE-LEVEL ON ERROR UNDO, THROW

How to log the line number of code that raises an error when the error is trapped using structured error handling

Steps to Reproduce

Clarifying Information

For purposes of this article, "client log" refers to a log file specified with the "-clientlog" client startup parameter, or any Unified Broker Server log such as an AppServer Server log or WebSpeed Server log.

Error Message

Defect Number

Enhancement Number

Cause

Resolution

Errors caught using structured error handling (a CATCH block or "ROUTINE-LEVEL ON ERROR UNDO, THROW") may be written to the client log by using the ERROR-STACK-TRACE and DEBUG-ALERT attributes of the SESSION handle as follows:

Enable SESSION:ERROR-STACK-TRACE to write a complete stack trace including line numbers to the error object's CallStack property. This may be done in code using the statement "SESSION:ERROR-STACK-TRACE = TRUE', or from the command line using the -errorstack client startup parameter.
Enable SESSION:DEBUG-ALERT to write all stack traces to the client log. This may be done in code using the statement "SESSION:DEBUG-ALERT = TRUE', or from the command line using the -debugalert client startup parameter.
If a CATCH block is used, after any custom error handling add an "UNDO, THROW <error object>" statement. This propagates the error out of the CATCH block so the DEBUG-ALERT functionality can further handle it.

As an alternative to throwing the built-in error, the CATCH block could write a custom alert-box message which could be captured in the client log with the 4GLMessages log entry type at logging level 2 or above. For AppServer or WebSpeed logging, it is not necessary to enable 4GLMessages; alert-box messages are always captured in AppServer and WebSpeed Server logs.

The following example code using the Sports 2000 sample database demonstrates the above techniques. Comment out individual sections of the code to see how what each technique does on its own as well as working together:

ROUTINE-LEVEL ON ERROR UNDO, THROW.

SESSION:DEBUG-ALERT = TRUE.
SESSION:ERROR-STACK-TRACE = TRUE.

DO TRANSACTION:
    FIND FIRST Customer
        WHERE CustNum = 1000        /* No customer 1000 exists in Sports2000 Customer table */
        .

    CATCH e AS Progress.Lang.SysError:
        MESSAGE 
'This is my custom error handling. Here is the stack trace at the time of the error:'
SKIP
e:CallStack
VIEW-AS ALERT-BOX.
   UNDO, THROW e.
    END CATCH.

END.

There is a performance impact associated with writing the stack traces. The performance cost is associated with storing the call stack information in the CallStack property of the error object. For this reason Progress does not recommend enabling SESSION:ERROR-STACK-TRACE for production use.

Workaround

Notes

References to Other Documentation:

OpenEdge Development: ABL Reference
OpenEdge Deployment: Startup Command and Parameter Reference
OpenEdge Development: Debugging and Troubleshooting

Progress Articles:

Why is the CallStack property of an error object empty/null?
How to turn off the Callstack (_stack) value in PASOE Data Object Service json response?

Keyword Phrase

Last Modified Date

11/20/2020 7:32 AM

How to log the line number of code that raises an error when using structured error handling

Files(0)

Was this article helpful?

Was this article helpful?

How to log the line number of code that raises an error when using structured error handling

Information

Related Articles