Re: Possible error codes for monitor

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

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