Re: Program failure analysis

On 10/12/2017 6:44 PM, Barbara Morris wrote:

On 2017-10-12 10:54 AM, Buck Calabro wrote:

...
As much as I like a good philosophical discussion, this is actual
program code that I'm working on.  There are two 'abnormal' code paths
within the ON-EXIT block:
1) An exception like array index error.  This will be trapped by
MONITOR...ON-ERROR.
2) An API call that executes with no exceptions, but returns an
unexpected result in the error code parameter.  MONITOR...ON-ERROR
doesn't trap these.

Could you move the API calls in the ON-EXIT to another procedure where
DUMP is allowed? I guess it depends on how much of the data from the
on-exit procedure you want to see in any dump output related to the API
calls in the ON-EXIT section.

The API calls are the cleanup in this case. There'd be no point in an
ON-EXIT if I did the actual work before ON-EXIT got called - which is
the same situation as before ON-EXIT came into being.

It's somewhat surprising that more RPG programmers haven't chimed in
with their pattern for logging at the moment of failure. That thousands
of programmers recreate errors in the dev environment is powerful
evidence that I need to rethink what I'm doing.

For this particular case, I can make the 'get profile handle' calls in
the main line, make the handle variables global, and use CEE4RAGE to
clean up after myself. I think that this thread has taught me that
ON-EXIT really really is for sub-procedures; blocks that do one thing.
At least I'll be less likely to misapply it next time :-)