Re: Possible error codes for monitor

Rob

In general, I agree with you. The instance I refer to is one where there is no reason at all to take a more detailed approach. If the data cannot be converted for whatever reason, the item in question is diverted to a kind of routing inbox - for someone to examine and process. And that is an adequate process for the customer for whom I wrote the program - not one of our products, but an exit from one of our apps.

You mention vendor changes - as it is our product against which I am writing this, that's covered. But you make a great point about processes less limited in scope.

But in general, you are spot on.

Hope that clears up my thinking!
Vern

At 04:03 PM 12/10/2007, you wrote:

Vern,

I differ. I at least make a token effort to determine what the error is
or trap more common errors. Like

monitor;
MyNbr=%dec(MyChar);
on-error InvalidNumeric;
InvalidNumeric(); // execute the invalid numeric subprocedure
on-error;
// catch all
AlertTheTroops();
endMon;

While you may think that the only possible error would be an invalid
numeric, you may decide to handle truncation, etc different. Things
change, like a new vendor package may change field sizes.

Also, OS changes occur. Like all those people who assumed that all write
errors were because of a duplicate record and then simply did a chain and
update to remedy it. Now they get errors like referential constraint
error, or trigger error, or ...

Notice the
on-error InvalidNumeric