Re: User-generated errors

On Thu, 2016-12-15 at 11:38 -0800, Alan Campin wrote:

Isn't that exactly what my standard error handler provides?

XVERRH_Throw('CPF9898':
CPF_MESSAGE_FILE_NAME:
'Field X is invalid');

And adds message storage for retrieval at a higher level.

Without looking/running the code... one of the problems is that the
sender becomes something it shouldn't be (or at least did way-back-when,
so may have changed if the message API's have changed since 5R3?).

Whats needed is a way of throwing a message up (down?) the stack, but
being able to signify that it came from a procedure "in the stack, but
higher (lower) than where the message is going"..

proc1>proc2>proc3> srvpgm_throw to(proc2) assender(proc3) (QMHSNDPM
kind of does this, as it doesn't define itself as the sender in the
message)

is quite obvious, but it could also be...

proc1>proc2>proc3> on error >remove_alloc_mem>proccleverlog> throw
to(proc2) assender(proc3)

or something similar... not perfect as it allows a kind of "spoofing" by
allowing any procedure (or counter from *) in the stack to be named as
the sender (but should not allow a false name/counter or a counter that
is up [down] more than the program stack that will get the message) even
if its no where near close to where the *escape happened but I don't see
any way to have it work "more sensibly" but then again, with great power
comes great responsibility.

I guess QMHSNDPM could do this (though why there are no message handling
procedure annoys me, especially as a program has a bigger overhead than
a procedure; a problem if you want to write programs that make full use
of all types of messaging and not just the odd escape message) if it was
modified to have two extra parameters:

FromCallStackEntry (Identical to Call Stack Entry)
FromCallStackCounter (Identical to Call Stack Counter)

I guess a few of the other message handling programs might also need
changing, possibly resendmessage, promotemessage etc.

Jon

.

On Thu, Dec 15, 2016 at 11:32 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

What he really needs is something I've been asking for for a while. In
addition to MONITOR which is RPG's "catch" we could use an RPG oriented
"Throw".

Anyone want to volunteer to open an RFE on that?


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Dec 15, 2016, at 11:40 AM, Brian Johnson <brian.johnson.mn@xxxxxxxxx>

wrote:

On Thu, Dec 15, 2016 at 10:36 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
wrote:

Procedure1 => Procedure2 => ErrorProcedure
I expected the MONITOR block in Procedure2 to catch the error, but it's
actually the MONITOR in Procedure1 that's catching it.

That's because you are sending the escape message to Procedure1. You need
to use '*' and '1' for call stack and offset parameters in ErrorProcedure
to send the message to the caller of ErrorProcedure.


--
Brian Johnson
brian.johnson.mn@xxxxxxxxx
--
This is the RPG programming on the IBM i (AS/400 and 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.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and 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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD