×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hello,
1) *PSSR won't catch file errors... unless you code INFSR(*PSSR), that
is. Even if you do, it only catches file errors for files that are
global to the module. Not for those local to the subprocedure.
2) *PSSR can call itself again when an error occurs. This makes it clumsy.
While I certainly see your point about *PSSR being a "catch-all"
routine... it's not a perfect solution for one. On the other hand, if
you do this:
MONITOR;
exsr MyMainLogic; // or callp
ON-ERROR;
// do catch-all logic here
ENDMON;
You will catch all errors, without futzing around with INFSR or worrying
about local/global scope. And you don't have to worry about it being
called in a loop because an error occurs in the ON-ERROR.
Granted, there are ways to make *PSSR work... but MONITOR is cleaner
and easier... and it can also handle errors (as opposed to just being a
catch-all) which means if you have to learn only one technique, you can
do it all with MONITOR.
I would suggest at least trying MONITOR in a few places, get acquainted
with it, and see if you like it. If you've used it a bunch of times and
you really still prefer *PSSR, then stick with *PSSR. But I personally
find MONITOR much easier and less clumsy.
On 9/28/2010 10:55 AM, hockchai Lim wrote:
There is no doubt that one should use monitor on places where failure is
likely to occur and handle that specific error accordingly. But if I want
to guarantee that my RPG program never goes into a MSGW status, I usually
use *pssr. Why wrap the entire main procedure with an ugly monitor opcode
when I can use a *pssr to provide me that guarantee.
midrange.com
