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


  • Subject: Re: Eval Exception Error Trapping
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 23 Jul 1999 14:08:37 -0500

Hans,

     I have to say that I really like the try/catch approach to error
handling.   (and, frankly, I *hate* the way error catching currently
works in RPG... its ugly, and often takes a lot of work to get it
to do what you want to do.)

I would, however, RPG-ize it a bit.   Make it work more like the
Select/When works now.  And make sure there is a way to determine
WHICH exception happened, and why...  (without having to resort
to various data structures such as the PSDS or INFDS)

maybe something like:
C                  TRY        ERRFLD
C         ..... insert one or more lines of code here...
C                  CATCH      ERRFLD = 'CPF2105'
C         ..... insert one or more lines of error handling code....
c                  CATCH      ERRFLD = 'CPF0001'
C         ..... insert one or more lines of error handling code....
C                  FINALLY
C         ....  more code again ...
C                  ENDTRY

Otherwise, I also like the way that C programs handle errors.
(check for a bad response, and then check errno to see what it
was, use strerror to get a text description, or use perror to
simply print that error)

As a third choice, I'd go for something like the CL MONMSG command...
Though this can get to be a bit awkward...  I'd prefer to have
something like try/catch where you can monitor multiple statements
of code all in one grouping...

Thats my 2 cents...

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.


boldt@ca.ibm.com wrote:
>
> Jon wrote:
> >Hans - I like the try/catch type approach in some ways but it is
>  overkill in
> >many ways. Why not simply permit the coding of the "E" extender on
>  numeric
> >operations? That way I can trap at the statement level if I wish.
>
> On the other hand, the E extender, as currently designed, already
> has serious limitations.  For example, coding E on a WRITE will
> trap file exceptions, but not program exceptions.  But on other
> opcodes, it does trap program exceptions.
>
> Perhaps it is overkill, but when writing new apps, it's the only
> exception handling method you need to know about.  Today, you need
> to know about INFSR's, *PSSR's, error indicators, extender E, etc.
> MONITOR is one easy-to-understand technique that can replace all
> others.
>
> 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.