Re: Is the 4gl 4.12/13/whatever compiler a bit smarter

>From: kerry@kcbbs.gen.nz (Kerry Sainsbury) >Subject: Is the 4gl 4.12/13/whatever compiler a bit smarter >Date: Wed, 25 May 1994 21:51:08 -0500 >X-Informix-List-Id: <news.6868> > >The 4.10 4GL compiler is a bit stupid. Are later versions smarter? >Specifically: > >MAIN > WHENEVER ANY ERROR STOP > CALL b() > CALL a() >END MAIN > >FUNCTION a() > WHENEVER ANY ERROR CONTINUE >END FUNCTION > >FUNCTION b() >DEFINE i INTEGER > LET i = 1 / 0 >END FUNCTION > >This program will *NOT* stop with an error message in function b. >It also really annoys me that I have to remember to put >WHENEVER ANY ERROR CALL serious_error in the front of every program >module if I want to use my own error handling routine. The WHENEVER ERROR (and WHENEVER WARNING and WHENEVER NOTFOUND) statements are compiler directives, more akin to #define in C than any normal I4GL statement, and as you have found out, they are not limited to the scope of a single function. This is a design decision which I happen to disagree with, but which cannot be changed without breaking lots and lots of code! It isn't a bug. Two changes would help you: (1) Allow WHENEVER ERROR outside the scope of functions. (2) A compiler directive to set the WHENEVER behaviours. >or: > >DISPLAY l_variable + 1 TO screen_field > `------v-------' >4GL seems incapable of coping with this sort of expression evaluation >anywhere. This is brain-dead behaviour, and could be fixed without breaking any existing code. I don't have a bug number for it, and it is more akin to a feature request than a bug. It is, however, a severe nuisance. >or: > >Why the hell can't I use the PRINT command in a function? It sure would >save some code duplication at times! Because it has been defined that you can't. I haven't checked to see what the reasoning is, and again, it could be fixed without breaking any existing code. It, too, is a feature request rather than a bug, but as you say, it would make life a lot easier. Thinking a little bit: one reason why PRINT isn't allowed in arbitrary functions is because you can call arbitrary functions in either the page header or the page trailer block, and if the function could do printing, it would cause problems. Have you ever tried to conditionally print different amounts of code in the page header on odd and even pages of a report? You can't -- the headers are of a fixed size. Since I4GL isn't prepared to handle variable length page headers and trailers, it can't allow you to call a function which can do printing. At the moment, no function can do printing, so there is no problem. It might have to stop you calling functions in headers, or it would have to cope with variable length headers. Actually, headers aren't as bad as variable length page trailers! >THE QUESTIONS: >Are any of these things considered bugs? FRs -- yes. Bugs: probably not, though I'm sympathetic... >Are any of these things likely to change in future versions? Maybe, but more likely not. >What is the ETA of 4GL++? >Is 4GL++ going to be backwards compatable with 4GL? I decline to offer comments on 4GL++ for fear of incriminating myself. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>