Re: The ILE Question I Forgot to Ask

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Arthur,

With ILE, exceptions are percolated up the stack till a handler is encountered.

I recommend a couple of resources:
ILE Concepts manual

Who knew you could do that with RPG IV?
http://www.redbooks.ibm.com/abstracts/redp4321.html?Open

RPG: Exceptions and Error handling Redpaper
http://www.redbooks.ibm.com/abstracts/redp4321.html?Open

> From the redpaper above:
"An overview of percolation is provided in the previous IBM Redbooks
publication (section
4.2.7.1 Call stack and error handling and section 4.2.7.2 Error
handling in ILE) but here we
give a brief explanation from the point of view of handling
exception/errors in an application.
In an OPM environment, a program that is well down the call stack receives an
exception/error. If the program does not have any exception/error
handling, the RPG default
handler will issue a function check message.

In an ILE environment, a subprocedure or a program that is well down
the call stack receives
an exception/error. If the subprocedure or program does not have any
exception/error
handling specified, the message is sent back up the call stack to the
calling procedure. If the
calling procedure does not have any exception/error handling defined,
the message is again
sent back up the call stack to the calling procedure and so on until
the AG control boundary is
reached.

It is important to note that messages are percolated to an AG control
boundary that may or
may not be the program that originally initiated the AG. Refer to the
section on Control
Boundaries Chapter 3 (ILE Advanced Concepts) of the in ILE Concepts manual.
If none of the subprocedures or programs in the call stack have
exception/error handling
defined, the message is re-signaled as an exception and control
returns to the subprocedure
or program that originally received the message and an attempt is made
to call the RPG
default handler. But subprocedures do not have a default RPG handler,
which means that the
call to the subprocedure causes an exception/error which, in turn, is
percolated up the call
stack. This process continues until a default handler can be called.
This means that a function
check may not be issued until an entry in the call stack is a mainline
program (which will have
a default error handler)."


HTH,
Charles Wilt

On Tue, Apr 21, 2009 at 9:34 AM, Arthur Marino <amarino@xxxxxxxxxxxx> wrote:
> Just got back from the RPG/DB2 Summit in Orlando. Scott, Jon, Susan,
> Paul, et al were all great.
>
> But I forgot to ask how I should handle unexpected errors in a
> prototyped procedure. The proc attempted to write a duplicate key and
> auto-cancelled. It returned to the caller and halted there, allowing me
> to dump, but that was too late, of course.
>
> Do I have to anticipate every possible error in the proc? Can't it be
> made to halt at the point of failure so I can get a dump at a point
> where it'll do me some good?
>
> Thanks,
> Arthur Marino
>
> This message, including its attachments, constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510.  This message is the confidential property of RockTenn, and disclosure is strictly limited to recipients intended by the sender.  Unless previously authorized in writing, this message does not constitute an offer, acceptance, or agreement of any kind.  This message may contain confidential attorney-client privileged information and attorney work product.  If you are not the intended recipient, or responsible for delivering e-mail to the intended recipient, you are advised that use, dissemination, forwarding, printing, or copying of this message is STRICTLY PROHIBITED.  If you receive this message in error, please notify the sender immediately by return e-mail and delete the message entirely from your system.  Sender is not liable for damage caused by viruses transmitted with this message, or errors or omissi!
>  ons in content caused by transmission.
> (c) RockTenn, Norcross, GA.
> --
> This is the RPG programming on the IBM i / System i (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.