Re: Trapping Errors in New Era of pain

Thanks Michele, We will be converting this code (not to New Era , no ****ing way) but not for another 6 months. As a workaround for my particular problem, any idea how to test for the existence of a file? if file does not exist, create and open it end if I can't use the ixFILE Object (getStatus) in the test condition because the file in question may already be open and thus I will not be able to get a handle on the file to open it giving me a 50050 error (can't open file). This is why I wanted to be able to trap the error and ignore it, but if I can't do that then I'd like to avoid the error. Thanks, John m.iacobellis@usa.net wrote in message <7bh4fi$1va$1@nnrp1.dejanews.com>... >In article <7bggi5$gbf$1@starburst.uk.insnet.net>, > "John Clynes" <jclynes@family.co.uk> wrote: >> Hi, >> I am trying to trap errors in New Era and can't. >> >> The version is 2.12 running on both NT4 and win3.11. >> >> I have tried different types of errors but it always ignores all whenever >> error statements. (or whenever any error) >> >> If this is a bug it is hard to believe....although with New Era the bounds >> of credulence are always stretched thin. >> >> Has anyone else had this problem? The code, as far as I can see is fine. >> Some examples would be >> >> FUNCTION X() >> >> whenever any error continue # or >> #whenever any error goto :ignore #defined label in this function >> #whenever any error call ignore_it # defined function >> #whenever any error stop >> >> do stuff >> do stuff >> do something that errors >> >> LABEL ignore_it: >> DISPLAY "This error was trapped and went to a label" >> >> END FUNCTION >> >> FUNCTION ignore_it() >> DISPLAY "This error was trapped" >> END FUNCTION >> >> If I use the LABEL I get a compilation error. (4414 - label used but not >> defined, which it is) >> If I call a defined function it doesn't call it when the error occurs. >> If I use continue or stop the behaviour is exactly the same as not using >> them. >> >> What the hell is going on? >> >> Anyone else seen this? >> >> Thanks, >> John >> >> > >John, > >I tried similar code on my 2.20 NewEra compiler and I didn't find any problem. > >I worked with 2.12 till 2 years ago and it was a very buggy release. > >If you can, upgrade! > >Michele > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

John Clynes <jclynes@family.co.uk> wrote: > >> I am trying to trap errors in New Era and can't. > >> > >> The version is 2.12 running on both NT4 and win3.11. > >> > >> I have tried different types of errors but it always ignores > >> all whenever error statements. (or whenever any error) > >> > >> If this is a bug it is hard to believe....although with New Era > >> the bounds of credulence are always stretched thin. > >> > >> Has anyone else had this problem? The code, as far as I can see > >> is fine. Some examples would be > >> > >> FUNCTION X() > >> > >> whenever any error continue # or > >> #whenever any error goto :ignore #defined label in this function > >> #whenever any error call ignore_it # defined function > >> #whenever any error stop > >> > >> do stuff > >> do stuff > >> do something that errors > >> > >> LABEL ignore_it: > >> DISPLAY "This error was trapped and went to a label" > >> > >> END FUNCTION > >> > >> FUNCTION ignore_it() > >> DISPLAY "This error was trapped" > >> END FUNCTION > >> > >> If I use the LABEL I get a compilation error. (4414 - label > >> used but not defined, which it is) > >> If I call a defined function it doesn't call it when the error > >> occurs. If I use continue or stop the behaviour is exactly the > >> same as not using them. > >> > >> What the hell is going on? > >> > >> Anyone else seen this? I normally deny all knowledge of NewEra, but at least some of this is explicable with reference to I4GL instead. BEWARE OF WHENEVER ERROR GOTO!!! The problem is not in function x(), but in function ignore_it(). That function doesn't have a label in it, but the WHENEVER directive in the previous function continues to apply -- it is a compiler directive, not a scoped statement. Further, before the DISPLAY statement in ignore_it(), there is an error check on the arguments passed to the function, not to mention the error checking after the DISPLAY. Both sets of error checking require a label which you have not supplied. IMNSHO, the only valid values for WHENEVER ERROR handling are STOP and CONTINUE. I use STOP when I am very sure that there should not be a problem, and CONTINUE when I think there might one day be a problem. Hence, I use WHENEVER ANY ERROR STOP most of the time, and temporarily reset it to WHENEVER ANY ERROR CONTINUE around SQL statements. I assume my forms will be present; my programs stop if the environment is screwed up because a form is missing. I assume that the forms I find are the same as the ones I expect to find; it is too damned hard to recover if the form exists but doesn't have the screen elements I expect to find on it. But SQL statements can fail at any time, perhaps because the DBA took the OnLine system off-line. That has to be accounted for in the code (even though there isn't much you can do if the OnLine system goes off-line). Oh, and I think that NewEra 3.x (where I'm not sure of the correct value for x) allows you to use a WHENEVER ERROR statement as the first executable statement in a function, and the new error handling regime prevails for the argument checking. I4GL still does its argument checking under the WHENEVER ERROR regime which applied at the end of the previous function. This deals with the LABEL problems at compile time. It doesn't help with why the error is ignored at run time. We need to know more about the 'do something that errors' to diagnose why the error handling is ignored. Is it an SQL statement that fails (eg referencing a non-existent table)? SELECT * FROM non_existent If this doesn't trigger the error handling, then you've got a bug. If it does, but your error-raising activity doesn't trigger the error handling, then there is a divergence of opinion about what constitutes an error.

Johathan, Thanks for your reply. The example I gave of code was a combination. When I tried it I tried them in isolation. (i.e I used a label only, or I used a function only, and took out other. This avoided any compiler confusion) Also, the reason I had to try labels or a function call was because trapping wasn't responding to stop or continue - luckily it didn't matter as it didn't respond to them (labels/functions) either. Equal in death. The reason I was trying to trap the error was because of a bug in new era. But I couldn't trap the bug because of a bug in error trapping. Hilarious. [expletives snipped] As far as what the error was, New Era was generous in its interpretation - any error, file i/o, setting an int to a char, whatever. Thanks again. John Jonathan Leffler wrote in message <36DE6A84.153F@earthlink.net>... >John Clynes <jclynes@family.co.uk> wrote: >> >> I am trying to trap errors in New Era and can't. >> >> >> >> The version is 2.12 running on both NT4 and win3.11. >> >> >> >> I have tried different types of errors but it always ignores >> >> all whenever error statements. (or whenever any error) >> >> >> >> If this is a bug it is hard to believe....although with New Era >> >> the bounds of credulence are always stretched thin. >> >> >> >> Has anyone else had this problem? The code, as far as I can see >> >> is fine. Some examples would be >> >> >> >> FUNCTION X() >> >> >> >> whenever any error continue # or >> >> #whenever any error goto :ignore #defined label in this function >> >> #whenever any error call ignore_it # defined function >> >> #whenever any error stop >> >> >> >> do stuff >> >> do stuff >> >> do something that errors >> >> >> >> LABEL ignore_it: >> >> DISPLAY "This error was trapped and went to a label" >> >> >> >> END FUNCTION >> >> >> >> FUNCTION ignore_it() >> >> DISPLAY "This error was trapped" >> >> END FUNCTION >> >> >> >> If I use the LABEL I get a compilation error. (4414 - label >> >> used but not defined, which it is) >> >> If I call a defined function it doesn't call it when the error >> >> occurs. If I use continue or stop the behaviour is exactly the >> >> same as not using them. >> >> >> >> What the hell is going on? >> >> >> >> Anyone else seen this? > >I normally deny all knowledge of NewEra, but at least some of this >is explicable with reference to I4GL instead. > >BEWARE OF WHENEVER ERROR GOTO!!! > >The problem is not in function x(), but in function ignore_it(). >That function doesn't have a label in it, but the WHENEVER >directive in the previous function continues to apply -- it is a >compiler directive, not a scoped statement. Further, before the >DISPLAY statement in ignore_it(), there is an error check on the >arguments passed to the function, not to mention the error checking >after the DISPLAY. Both sets of error checking require a label >which you have not supplied. > >IMNSHO, the only valid values for WHENEVER ERROR handling are >STOP and CONTINUE. I use STOP when I am very sure that there should >not be a problem, and CONTINUE when I think there might one day be >a problem. Hence, I use WHENEVER ANY ERROR STOP most of the time, >and temporarily reset it to WHENEVER ANY ERROR CONTINUE around SQL >statements. I assume my forms will be present; my programs stop if >the environment is screwed up because a form is missing. I assume >that the forms I find are the same as the ones I expect to find; it >is too damned hard to recover if the form exists but doesn't have the >screen elements I expect to find on it. But SQL statements can fail >at any time, perhaps because the DBA took the OnLine system off-line. >That has to be accounted for in the code (even though there isn't >much you can do if the OnLine system goes off-line). > >Oh, and I think that NewEra 3.x (where I'm not sure of the correct >value for x) allows you to use a WHENEVER ERROR statement as the >first executable statement in a function, and the new error handling >regime prevails for the argument checking. I4GL still does its >argument checking under the WHENEVER ERROR regime which applied at >the end of the previous function. > >This deals with the LABEL problems at compile time. >It doesn't help with why the error is ignored at run time. > >We need to know more about the 'do something that errors' to >diagnose why the error handling is ignored. Is it an SQL statement >that fails (eg referencing a non-existent table)? > > SELECT * FROM non_existent> >If this doesn't trigger the error handling, then you've got a bug. >If it does, but your error-raising activity doesn't trigger the >error handling, then there is a divergence of opinion about what >constitutes an error. >

Thanks for all the replies. The only way of getting around this is using C. From what I've got back (Tech support and others) labels are a problem in this release 2.12. (error 4414) Solution is to call functions (on error call funX). (of course that doesn't work in this particular release either, so basically I can't trap any errors, great, makes my job easier) The file error (error 50050) was also an known issue for v2.0 but never fixed for this release. Bad hair day or something. So I was getting an error because of a file i/o bug. I couldn't trap this error because of a bug in error trapping. Then the spider ate the fly. What rigourous testing procedures these guys go to. Thank God they don't make food. or kids toys. or sexual props. Anyway, thanks lots! John Jonathan Leffler wrote in message <36DE6A84.153F@earthlink.net>... >John Clynes <jclynes@family.co.uk> wrote: >> >> I am trying to trap errors in New Era and can't. >> >> >> >> The version is 2.12 running on both NT4 and win3.11. >> >> >> >> I have tried different types of errors but it always ignores >> >> all whenever error statements. (or whenever any error) >> >> >> >> If this is a bug it is hard to believe....although with New Era >> >> the bounds of credulence are always stretched thin. >> >> >> >> Has anyone else had this problem? The code, as far as I can see >> >> is fine. Some examples would be >> >> >> >> FUNCTION X() >> >> >> >> whenever any error continue # or >> >> #whenever any error goto :ignore #defined label in this function >> >> #whenever any error call ignore_it # defined function >> >> #whenever any error stop >> >> >> >> do stuff >> >> do stuff >> >> do something that errors >> >> >> >> LABEL ignore_it: >> >> DISPLAY "This error was trapped and went to a label" >> >> >> >> END FUNCTION >> >> >> >> FUNCTION ignore_it() >> >> DISPLAY "This error was trapped" >> >> END FUNCTION >> >> >> >> If I use the LABEL I get a compilation error. (4414 - label >> >> used but not defined, which it is) >> >> If I call a defined function it doesn't call it when the error >> >> occurs. If I use continue or stop the behaviour is exactly the >> >> same as not using them. >> >> >> >> What the hell is going on? >> >> >> >> Anyone else seen this? > >I normally deny all knowledge of NewEra, but at least some of this >is explicable with reference to I4GL instead. > >BEWARE OF WHENEVER ERROR GOTO!!! > >The problem is not in function x(), but in function ignore_it(). >That function doesn't have a label in it, but the WHENEVER >directive in the previous function continues to apply -- it is a >compiler directive, not a scoped statement. Further, before the >DISPLAY statement in ignore_it(), there is an error check on the >arguments passed to the function, not to mention the error checking >after the DISPLAY. Both sets of error checking require a label >which you have not supplied. > >IMNSHO, the only valid values for WHENEVER ERROR handling are >STOP and CONTINUE. I use STOP when I am very sure that there should >not be a problem, and CONTINUE when I think there might one day be >a problem. Hence, I use WHENEVER ANY ERROR STOP most of the time, >and temporarily reset it to WHENEVER ANY ERROR CONTINUE around SQL >statements. I assume my forms will be present; my programs stop if >the environment is screwed up because a form is missing. I assume >that the forms I find are the same as the ones I expect to find; it >is too damned hard to recover if the form exists but doesn't have the >screen elements I expect to find on it. But SQL statements can fail >at any time, perhaps because the DBA took the OnLine system off-line. >That has to be accounted for in the code (even though there isn't >much you can do if the OnLine system goes off-line). > >Oh, and I think that NewEra 3.x (where I'm not sure of the correct >value for x) allows you to use a WHENEVER ERROR statement as the >first executable statement in a function, and the new error handling >regime prevails for the argument checking. I4GL still does its >argument checking under the WHENEVER ERROR regime which applied at >the end of the previous function. > >This deals with the LABEL problems at compile time. >It doesn't help with why the error is ignored at run time. > >We need to know more about the 'do something that errors' to >diagnose why the error handling is ignored. Is it an SQL statement >that fails (eg referencing a non-existent table)? > > SELECT * FROM non_existent> >If this doesn't trigger the error handling, then you've got a bug. >If it does, but your error-raising activity doesn't trigger the >error handling, then there is a divergence of opinion about what >constitutes an error. >