Re: communicating with messages

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> I read an atricle a while back which put forward the idea of emulating
> try/catch blocks by using the message APIs.
You mean the one by Greg Helton?  (This requires a ProVIP account on 
iSeries Network to read:)
http://www.iseriesnetwork.com/article.cfm?id=19628

[SNIP]
> monitor;
> // process task...
> processTask();
> on-error   TASK_HALTED;
>  someCode();
> on-error   TASK_SUSPENDED;
>  someOtherCode();
> on-error;
>  inTrouble();
> endmon;
Unfortunately, RPG's MONITOR and ON-ERROR opcodes are flawed in that they 
can only monitor for RPG status codes, and not the message ID's of *ESCAPE 
messages.
What you'd have to do instead would be something like this:

monitor;
  processTask();
on-error;

  msgid = getMsgId();

  select;
  when msgid = TASK_HALTED;
    doSomething();
  when msgid = TASK_SUSPENDED;
    doSomething();
  other;
    propigateError();
  endsl;
endmon;

The getMsgId() subprocedure would call the QMHRTVPM API to retrieve the 
last escape message so that you'd know the message ID of the error. (This 
is what the catch() subprocedure in Helton's article does... it doesn't 
actually catch anything, it just retrieves the message id.)
The propigateError() subprocedure would use the QMHRSNEM API to re-send 
the escape message to the caller (thus ending this subprocedure abnormally 
and forcing it's caller to MONITOR for the error...)  An example of this 
type of logic can be found in the archives at the following link:
http://archive.midrange.com/rpg400-l/200510/msg00610.html

And, of course, the processTask() subprocedure would issue errors using 
the same logic as the "Throw" subprocedure from Helton's article, just as 
you outlined in your sample code.
> Is this possible? Where would I find examples for this kind of thing? Does
> my question make any sense at all?
Heh.. it's actually the way error handling is SUPPOSED to work in OS/400. 
(or i5/OS). One of the greatest things about our system is that messages 
are not ignored by default -- when a procedure reports an error, and you 
don't handle it, the program crashes.  That's great because you don't find 
out 15 steps later in your program that something's not right.  You don't 
spend hours trying to backtrack and find out what's wrong.  When something 
fails, the program blows up right then and there unless the programmer was 
explicitly coding for that error to occur.
Using that paradigm makes programs more robust, and provides better 
troubleshooting when something fails.