Re: Checking datatype of CHAR variable in 4GL

In article <34ED84EF.4FDB5274@rl.is>, John H. Frantz <john@rl.is> wrote: >1. With "whenever any error continue" the programmer has decided to trap >error-codes himself. Conversion error-codes don't automatically crash >the program and, reasonably, shouldn't automatically log to the error >log. If the program is handling the error-code it can decide whether to >log an error message. I disagree. First of all, by using AnyError scope (as opposed to plain old WHENEVER ERROR, you use WHENEVER ANY ERROR), you are saying you WANT to know about all abnormal conditions... for which you are free to choose your own handling, or no handling. Second of all, aside from bugs, [-: no error code "automatically crashes a program". Many errors would have you wanting to keep the program going, if for no other reason than to dump diagnostic info, rollback partial work, inform the user, set resumption points, or whatever... >2. The manuals effectively say that within a "whenever error continue" >block, SQL error-codes aren't logged. While nothing is specifically said >about the "whenever any error" statement, reason says it should be >consistent with "whenever error". SQL error-codes are sometimes normal >and so are conversion error-codes. I missed that part... >3. I can't imagine anyone being interested in a log file growing at a >mad rate describing conversion error-codes that were handled by the >program. To say that the error log isn't really an error log but a >message log is kind of circumventing the issue. My point is, that conversion errors are rarely expected behavior, unless validating user input or doing date arithmetic with year-month intervals. If conversion errors are rampant in any program *I'm* responsible for, I want to know where they're coming from. >I do agree that the newer error handling methods in 4gl are an >improvement. It would even be better with this seemingly minor >adjustment of not logging errors that weren't errors. Agreed. I'd also like to research why module/line info isn't coming across (perhaps Jonathan remembers). The error routines will provide it if its available; it's not "bubbling up" for those cases... my guess is that it's due to use of internal-standard conversion routines that aren't designed to pass upward toos-specific info. (And keep in mind that if 4GL were changed to provide such infrastructure, there could be performance penalties to existing programs...) >John H. Frantz Power-4gl: Extending Informix-4gl >john@rl.is http://www.rl.is/~john/pow4gl.html -- Alan Denney yosemite_at_netcom.com Look for me on the California Attorney General's Tamagotchi-abuser CD-ROM.