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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact copyright@midrange.com.

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.