Re: converting to service program etc

I can certainly see where a flexible approach like that would be useful.

It's not always practical but I definitely prefer having the only OUT value
from a subprocedure call as the return variable.
This lends itself to writing more expressive code in my view.

And I like the idea of the built-in error handling routing my code to the
appropriate place on error, rather than having to code it manually based on
return parameters.
Using built-in error handling allows you to trap your error higher up in
the call stack (should that be appropriate) without you having to wrangle
parameters through several programs / subprocedures to facilitate it.

But at the moment I'm having to deal with a lot of legacy code that is
running in a different activation group to my code - it's mostly in *DFT.
ILE errors will only propogate to the activation group boundary which means
that if I throw an error (send an escape message) in my ILE activation
group, a program running in *DFT cannot MONITOR (or MONMSG) to trap the
error because it won't get that far.

In this case I would be forced to pass back an error parameter to indicate
failure
So I think the mixed approach would work well for this type of scenario.

Craig


On Thu, 21 Feb 2019 at 07:46, Thomas Raddatz <thomas.raddatz@xxxxxx> wrote:

We adopted the error handling mechanism of the IBM APIs. Parameter
o_errMsg is defined as *OMIT and *NOPASS. It is always the last parameter
in the parameter list. The source code dealing with the error looks like
this:

// If the message parameter (o_errMsg) has been passed, ...
if (%parms() >= %parmnum(o_errMsg));
// ... check if it has been omitted:
// When it has been omitted, ignore the error, else ...
if (%addr(o_errMsg) <> *null);
// ... return the error to the caller
o_errMsg = errMsg;
endIf;
else;
// ... else send an escape message
if (errMsg.msgID <> '');
sndPgmEscMsg(errMsg);
endIf;
endIf;

- Thomas.

-----Ursprüngliche Nachricht-----
Von: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] Im Auftrag von
Barbara Morris
Gesendet: Mittwoch, 20. Februar 2019 20:07
An: rpg400-l@xxxxxxxxxxxxxxxxxx
Betreff: Re: converting to service program etc

On 2019-02-17 6:45 PM, Craig Richards wrote:

A few other things you end up having to think about when you start using
sub-procedures:

- You now want to return a value to be sensibly used in an

expression -

but how do you tell the caller when something goes wrong?
- Generally I THROW an error in the sub-procedure and catch it in

a

monitor block surrounding the sub procedure call (at some level)

If you

haven't seen this technique before it's a nice one to know.

Another related way to handle this issue is to also add an optional
parameter to receive error information. If the parameter isn't passed,
send the exception.

Here's an RPG Cafe blog post I wrote about this issue a few years ago.

https://www.ibm.com/developerworks/community/blogs/b542d3ac-0785-4b6f-8e53-f72051460822/entry/return_code_or_exception?lang=en

--
Barbara

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the
sender.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com