RE: Eval Exception Error Trapping -- RPG400-L

Looks pretty good!

-----Original Message-----
From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com]
Sent: Friday, July 23, 1999 2:04 PM
To: RPG400-L@midrange.com
Subject: Re: Eval Exception Error Trapping


Joe wrote:
>I recently got an error on the EVAL statement "The target for a numeric
>operation is too small to hold the result (C G D F)."
>
>I know what the problem is and have corrected it by increasing the
field
>size.  Luckily I was available when the error occurred and was able to
>re-run the procedure.
>
>My question is:  Is there any way to trap for this error in the RPG
program?
>I have read in the manuals that the exception error will occur when the
>result is too big to fit into the variable. But no where did I find
anything
>telling me how to test for the error so that I could do some other
>processing and the program will not bomb in production.  In this case,
it
>was a percentage of change calculation and I would put something on the
>report to indicate that the calculation could not be made.  The only
idea I
>can think of would be to use a very large working variable for all my
EVAL
>statements and then test the work field for > the largest value that
would
>fit in the field that I really want to use (like on the report).
>
>There has to be a better way.  Any suggestions would be appreciated.

As someone already mentioned, you can use the *PSSR.  But that
solution, frankly, (hmmm, what's the right word?) sucks.  You
need to code TAGs and GOTOs, and if you want to handle exceptions
in several places, things start to look ugly fast.  Unfortunately,
at the moment, that's the best solution available.

You can code things a little more cleanly if you code your
arithmetic operation as the only operation in a procedure and code
a *PSSR to handle the exception in that procedure.  In that case,
use a RETURN statement in the *PSSR to exit the procedure.  You
could design the procedure to return *ON if the operation was
successful and *OFF if the operation failed.  This avoids having
to code messy GOTO/TAG statements, but it's still clumsy.

So, how about some improvement in RPG's exception handling?  Well,
we hope to have something better in a future release, something
like try and catch in Java.  Here's a small sample of what you
might be able to code in the future.  (Yes, this sample also
demonstrates the infamous CF-Spec!)

-----------------------------------------------------------------
     D num             s              3p 0 inz(999)
     CF monitor
     CF    num = num + 1
     CF    dsply num
     CF on-error 103
     CF    dsply 'Numeric overflow'
     CF endmon
     CF *inlr = *on
-----------------------------------------------------------------

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
* This is the RPG/400 Discussion Mailing List!  To submit a new
*
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe
*
* from this list send email to MAJORDOMO@midrange.com and specify
*
* 'unsubscribe RPG400-L' in the body of your message.  Questions should
*
* be directed to the list owner / operator: david@midrange.com
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *