× 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.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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 [javascript protected email address].

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