Re: Ending a program from within a procedure

Reading this thread I miss the mentioning of the Condition Handler APIs: 
CEEHNDLR and CEEHDLU. 

It has to be registered at the beginning of a programme and unregistered at the 
end (of course). It requires (a) special procedure(s) to handle errors. You can 
tell what action to be taken: perculate, promote, etc.

Joe Pluta wrote an article in MC on this in 2001.

Are those APIs not intended to do what you want to do? Or is it it just one of 
the many (failed?) attempts to get a decent error handling routine in an RPG 
programme?

Just wondering.

Regards,
Carel Teijgeler 

*********** REPLY SEPARATOR  ***********

On 25-7-05 at 18:26 Paul Morgan wrote:

>Joe,
>
>All just because the exception handling model on the 400 (escape messages)
>doesn't allow for automatic propagation up the call stack.  You either
>handle it at the target of the escape message or the system takes over with
>some default handling.  Because of that model your subroutine has to have
>knowledge of the top level entry point.  That's unnecessary cohesion
>between
>the subroutine and the 'top level' point.
>
>Better would be the subroutine throwing an exception to it's caller
>(where's
>the RPG THROW opcode?).  Let the caller decide to handle the exception or
>if
>it's ignored it gets automatically bubbled up to it's own caller.
>Eventually it would then reach your 'top level' point that would handle the
>exception. If it's not handled it would reach the top of the call stack and
>get some default handling like ending the job or breaking on QSYSOPR.
>
>Paul
>
>-- 
>Paul Morgan
>Senior Programmer Analyst - Retail
>J. Jill Group
>100 Birch Pond Drive, PO Box 2009
>Tilton, NH 03276-2009
>Phone: (603) 266-2117
>Fax:   (603) 266-2333
>
>Joe wrote
>
>> I mildly disagree.  I believe there are two kinds of errors: expected
>> and unexpected.  Expected errors are recoverable conditions that a
>> calling procedure might be able to rectify.  Unexpected errors signal
>> horrible fatal conditions (like a master file not found) and cannot be
>> recovered from.  Adding code to test for these conditions is unnecessary
>> and counter-productive.
>>
>> Instead, I register a "top level" entry point.  This is where any
>> unexpected errors should go.  When an error occurs, I simply send an
>> exception message to that level.  It automatically cleans up the stack
>> and allows me to notify the operator of the condition.  This is really
>> useful in situations where the procedure wouldn't normally return an
>> error.
>
>
>
>-- 
>This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
>To post a message email: RPG400-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
>or email: RPG400-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/rpg400-l.