Re: Eval Exception Error Trapping

Hans,

An example of when we use the *PSSR:

In our entry/update programs we update data base files through EXCPT (which
does not take an error indicator).  Sometimes an update is rejected by the
data base (e.g. a change to a field that is used as an alternate, unique
index causes a duplicate record error).  In the most recent versions of
these programs the *PSSR is used to handle this exception.  The *PSSR sets
an indicator and returns to *DETL.  Alas, this causes the main line to be
somewhat messy.

> 1) What do you normally do in a *PSSR?  Do you do more than
>    DUMP and give the user a "submit an APAR" message?

Set an indicator to inform the main line that it is going through error
recovery instead of initialization; put the message ID of the error in the
error text that will be shown to the user.

> 2) If you return back into the program, where do you normally
>    resume processing?  Also, how do you distinguish between
>    expected and unexpected exceptions?

We return to *DETL; the main line skips initialization and redisplays the
screen, with the error text.  We do not distinguish between errors.

> 3) In what situations would you use a *CONTINUE option on the
>    ENDSR?

In those situations where we know an error might occur, but preventing it
would be impractical.
For instance:
- Chances of data base errors are growing, with the expanding possibilities
of putting constraints in the data base.  Especially when adding constraints
to an existing data base, it is good to know that existing programs won't
bomb, when they violate a rule that was not known when they were created.
- The infamous overflow.  In commercial applications it is not very
practical to make amount fields big enough to accommodate for the largest
number times the highest price (would make printing invoices very
interesting :-).  That leads to code like:
CF  IF number * price <= Maximum_Value
CF     EVAL amount = number * price
CF  ELSE
CF     signal the error to the user
CF  ENDIF
(assuming we have CF-specs, that is).

Joep Beckeringh


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *