Re: communicating with messages -- RPG400-L

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 oniSeries 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 theycan only monitor for RPG status codes, and not the message ID's of *ESCAPEmessages.


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 thelast escape message so that you'd know the message ID of the error. (Thisis what the catch() subprocedure in Helton's article does... it doesn'tactually catch anything, it just retrieves the message id.)

The propigateError() subprocedure would use the QMHRSNEM API to re-sendthe escape message to the caller (thus ending this subprocedure abnormallyand forcing it's caller to MONITOR for the error...) An example of thistype 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 usingthe same logic as the "Throw" subprocedure from Helton's article, just asyou 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 messagesare not ignored by default -- when a procedure reports an error, and youdon't handle it, the program crashes. That's great because you don't findout 15 steps later in your program that something's not right. You don'tspend hours trying to backtrack and find out what's wrong. When somethingfails, the program blows up right then and there unless the programmer wasexplicitly coding for that error to occur.

Using that paradigm makes programs more robust, and provides bettertroubleshooting when something fails.