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 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.
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.
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.
Other than by setting a breakpoint before the error, of course. ...
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.
Flag this post as spam/abuse.
[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]
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.