Re: WHENEVER ANY ERROR

This is a multi-part message in MIME format. --------------30B818CB3DC27E9B23CD9F3B Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Leffler wrote: > Jason Harris (jharris@westpac.com.au) wrote: > }My 0.02 worths. > } > }I always thought that WHENEVER ERROR is a "COMPILER DIRECTIVE" and > }has no effect at run time. Code sequentially in the file after the > }WHENEVER ERROR statement will follow whatever is set. All the way > }through the program until the next WHENEVER ERROR is hit. > } > }It is evaluated at COMPILE time not RUN time. > > It is a compiler directive. It affects the code generated at compile time, > which in turn affects the behaviour of the code at run time, of course. > One of the problems with WHENEVER as a compiler directive is that you > cannot place it just anywhere in the source code; it is only allowed where > an executable statement is allowed -- despite it being a compiler > directive. > > What I was saying about WHENEVER ERROR GOTO is precisely the behaviour you > talk about -- that the code sequentially in the (source) file after the > WHENEVER ERROR statement will use whatever error handling is set all the > way through the program until the next WHENEVER ERROR is hit. That means > that if you say WHENEVER ERROR GOTO Label1 in FunctionA and don't turn it > off again before the END FUNCTION for FunctionA, then the FunctionB which > follows FunctionA in the source file needs a LABEL Label1 in it too, and > the same for every following function. In my view, this is seldom the > desired behaviour; however, it is the implemented behaviour and it always > has behaved like that. > > Yours, > Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> > PS: Warning I do not reply to messages with anti-spam in the return path. > > }johnl@informix.com (Jonathan Leffler) wrote: > }>Peter Lancashire <Peter.Lancashire.PL1@bayer.co.uk> wrote: > }>>Alan Denney wrote: > }>>>Jojean <jojean@aol.com> wrote: > }>>>>We are changing some 4GL programs to use WHENEVER ERROR to > }>>>>WHENEVER ANY ERROR. > }>>>Good move, generally. > }>> > }>>I have found a nasty bug in 4GL 6.02 on SCO where attempts to turn off > }>>the error trapping fail. This results in a C error in the next function > }>>when it can't find the label the WHENEVER ERROR GOTO directive referred > }>>to in the previous function. > }> > }>This is a (mis)feature of the WHENEVER statement, rather than a bug per > }>se. If you use WHENEVER ANY ERROR GOTO in FunctionA(), then you should > }>remember to turn it off (with WHENEVER ANY ERROR STOP) before the END > }>FUNCTION for FunctionA(). If you don't, then the code which pops the > }>arguments to FunctionB() which follows will use the same error handling > }>as FunctionA(), so you have to have the same label in FunctionB() as you > }>had in FunctionA(). [...] > }> > }>Remedies: > }>1. Don't use WHENEVER ... GOTO > }>2. Limit the scope of WHENEVER...GOTO to a single function. > }>[...] My approach to error handling is to use "whenever any error continue" at the top of every 4gl module. I then use a library function that I created to do the error handling. I write a lot of heavy duty data manipulation apps that run against a 24x7 reservation system, so error handling is very serious business over here. In addition to the whenever statement, I also use "defer interrupt" and "defer quit" in the beginning of the main function. All sql statements follow this scenario: if int_flag or quit_flag then return false end if sql statement goes here let g_error_code = status call ck_error(g_error_code, sqlca.sqlerrd[2], NO_ROLL, ABORT, "%M% %I% %C%) If an interrupt/quit is trapped (kill -2 kill -3), the logic train backs out of the calling functions back to the original calling function which then calls an "orderly shutdown" function. The error function returns without doing anything if the error code is 0, or not found. If the error code is a real error, the function displays a cleaned up error message (using err_get) and module name, version #, and line #. Depending on the arguments passed, the transaction may be rolled back and the application may be aborted. The messages displayed all go to standard output which is redirected to append the log file. The drawbacks to this methodology are 1. You're hosed if you forget to put ck_error() after every sql statement - strange things happen when the program continues after an error. 2. Using "any" in the statement means you better be careful with assignments and any other statements that may error. 3. Development of the application should proceed with the "whenever" statement commented out until ready to test. In general, I like this method much better than any of the previously mentioned methods (and I hate the way errorlog formats the error messages and doesn't tell you where the error occured). My employer probably won't let me post the source, so you will have to write your own if you like this idea.... --------------30B818CB3DC27E9B23CD9F3B Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jim Young Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Jim Young n: Young;Jim org: Choice Hotels, International adr: 4225 E. Windrose Drive;;;Phoenix;AZ;85032;US email;internet: jim_young@choicehotels.com title: Databoy tel;work: (602) 953-4421 note: This guy is a lunatic. x-mozilla-cpt: ;0 x-mozilla-html: TRUE end: vcard --------------30B818CB3DC27E9B23CD9F3B--