RE: Quieter Monitors

How about this:

Imagine you have an ungodly complex expression to form a part number out
of several fields:

// With Monitor
Monitor;
PartNo = UngodlyComplexExpression;
On-Error;
PartNo = '';
EndMon;

// Without Monitor
If Ungodly = www And
(Complex >= yyy And Complex <= zzz) And
...
//Etc.
PartNo = UngodlyComplexExpression;
Else;
PartNo = '';
EndIf;

You can't be absolutely sure that the second example won't throw an
escape message if the source fields (or its constraints) change in the
future.

--
Saludos
Antonio Salazar

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Rory Hewitt
Sent: Tuesday, February 23, 2010 11:19 AM
To: RPG programming on the IBM i / System i
Subject: Re: Quieter Monitors

Jon,

If we discount the 'problem' with the system having to recover from
exceptions (which may not be an issue with MONITOR), we're left with the
problem that too much code (that I see, anyway), is simply 'wrapped' in
a
MONITOR block, as if that's good enough. So maybe it's a coding problem
rather than a problem with MONITOR, per se.

However, for people who use MONITOR, there appear to be 2 possible
approaches:

1. Wrap a single MONITOR clause around a long chunk of code (I've even
seen
an entire main procedure wrapped in a single MONITOR clause). OK, it
works,
but it's really no different than a *PSSR (which I use :). If the
ON-ERROR
clause does something useful, it's OK, but as often as not it simply
sends
an error message.

2. Wrap individual sections in a MONITOR clause (typically where a
problem
might occur). The section might be a file read 'section' or a few lines
of
complex code or whatever. But in this case, why is it better than using
explicit error-checking?

Maybe I'm just used to seeing MONITOR used badly?

If you're complaining *(rightly!) about programming where you don't find
out
until 60 lines later that something was wrong, then it's not the "older
programming technique" that's the problem - it's the older programmer!

As far as seeing what the code path should be, how it this worse than
using
MONITOR to avoid e.g. array index errors:

// Check for errors before processing
if a = 0 or
array.ptr(a) = null or
array.len(a) < 0;
throwError;
endif;

// Load newvar
varptr = array.ptr(a);
newvar = %subst( var : 1 : array.len(a) );

I know - it's a nice simple example. Can you show me an example of code
that
uses MONITOR that couldn't equally clearly be written using specific
error
checks?

Maybe it's the comments that make it clear? <grin>

Rory

p.s. If you throw out the baby with the bathwater, all you get is a wet,
critically injured baby. And no-one wants that.

On Tue, Feb 23, 2010 at 5:50 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

On Feb 23, 2010, at 7:52 AM, rpg400-l-request@xxxxxxxxxxxx wrote:

I guess I prefer to write code which up-front checks (and caters)
for as
many errors as I can think of. Of course this means that the code is
full of
little IF-clauses checking for this error and that. So I'd be in
your latter
group.

I've never liked the MONITOR op-code, because it allows developers
to rely
on the system to catch things which they should have checked for in
the
first place. In Scott Klement's article which Kurt linekd to, Scott
uses his
CleanUp() procedure to clean up job log errors that might happen if

he

attempts to divide by zero. Me, I would have checked for zero before
the
divide. Likewise with the other errors.

Sorry Rory, on this one I have to (almost) 100% disagree with you.

Of course any programming technique can be abused - but in my opinion
the beauty of Monitor (i.e. try/catch) coding is that it a) makes it
obvious what the intended code path was and b) exactly which types of
error the programmer anticipated and how they are handled. You can
never tell that for sure with the older programming techniques. It is
sooooo much better than encountering a test on a variable and then
finding out 60 lines later why the programmer did it. And please don't
try to convince me that comments are the answer to that problem <grin>

The job log issue is a design "feature" that should be fixed by IBM -
but the coding technique is a good one. DOn't throw out the baby with
the bath water.

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com