Re: Program failure analysis

Buck,

In one of your earlier posts you wrote that you never ever want a program to go into MSGW. That implies that you need some sort of post mortem logging.

OTOH, if you do allow a program to go into MSGW in case of an unforeseen condition, you have a near perfect situation for investigating what went wrong. That may be the choice (conscious or by default) of many programmers. So you have to weigh the cost of an occasional MSGW against the cost of handling every possible condition.

Joep Beckeringh


Op 13-10-2017 om 16:15 schreef Buck Calabro:

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 :-)