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.
