Structured error handling and debugging

Posted by Stefan Drissen on 13-Mar-2014 03:27

I am using ROUTINE-LEVEL ON ERROR UNDO, THROW with one CATCH in the main block of an AppServer entry procedure.

This seems to render the debugger useless, since any error is picked up by the CATCH in the main block, resulting in all context of any internal procedure which caused the error being lost since it is out of scope.

This seems to be where -undothrow 1 could become useful - ie remove the routine-level on error statement and use -undothrow 1 in testing / production and leave it out in development?

All Replies

Posted by Frank Meulblok on 13-Mar-2014 03:50

"all context of any internal procedure which caused the error being lost"

You mean the ABL stack trace ?

In that case, you can use the -errorstack startup parameter / SESSION:ERROR-STACK-TRACE to get that stored in the exception objects, and retrieve it via the CallStack property of the Progress.Lang.Error object.

Posted by Stefan Drissen on 13-Mar-2014 07:15

No, I mean being able to view the entire state including all locally scoped variables, input output parameters, scoped buffers etc.

Ideally the debugger should be able to stop between the error and the error being caught.

Posted by Evan Bleicher on 14-Mar-2014 15:47

Stefan, you are correct.  The debugger works at the ABL statement level.  By this I mean that if the application is using the debugger and it is currently on an ABL statement in a block which is about to error and then if you STEP, the AVM and the Debugger will be at the next statement which may be in the CATCH block.  In this case you will not have access to the locally scoped data.  There currently is no mechanism to have the debugger give you an opportunity to inspect the locally scoped data prior to executing the CATCH block.

Posted by Thomas Mercer-Hursh on 14-Mar-2014 16:05

Other than by setting a breakpoint before the error, of course. ...

Posted by Peter Judge on 17-Mar-2014 08:11

That sounds like a useful idea.
 
You can – as an alternative or workaround – set a breakpoint on error (any or any number). From memory, you can do this in the Breakpoints view in the Debug perspective. This will  effectively do what you want (ie stop execution when the error occurs and keep program/stack state).
 
-- peter
 
 
[collapse]
From: Stefan Drissen [mailto:bounce-14941@community.progress.com]
Sent: Thursday, 13 March, 2014 08:16
To: TU.OE.Development@community.progress.com
Subject: RE: Structured error handling and debugging
 
Reply by Stefan Drissen

No, I mean being able to view the entire state including all locally scoped variables, input output parameters, scoped buffers etc.

Ideally the debugger should be able to stop between the error and the error being caught.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Stefan Drissen on 17-Mar-2014 15:48

[quote user="Peter Judge"]You can – as an alternative or workaround – set a breakpoint on error (any or any number). From memory, you can do this in the Breakpoints view in the Debug perspective. This will  effectively do what you want (ie stop execution when the error occurs and keep program/stack state).[/quote]

Now that looks interesting! Thanks!
The 'any error' option seems a bit over zealous - a FIND tt NO-ERROR also fires an 'error' when the record is not available - but 'any unsuppressed error' seems to do the trick!
Just need to ensure the debugger is fired up and breaking before any errors fly along.

Posted by Stefan Drissen on 19-Mar-2014 01:50

Just a quick update on this. 'any unsuppressed error' does not help, since a caught error seems to be considered suppressed. On error number # does do the trick however.

This thread is closed