[Coco] Error codes on SECB
lost at l-w.ca
Sat Nov 18 01:29:09 EST 2006
Diego Barizo wrote:
> I checked on the "Quick reference guide" and the NE error is not listed.
> Also, this short program gives no number
> 10 ON ERR GOTO 1000
> 20 LOAD"PPPP"
> 30 STOP
> 1000 ? ERNO,ERLIN
> 1010 END
> If I change line 20 for WOAD "PP" I get the expected results for an SN error
> BUT... If after the first program ends, I type ? ERNO, I do get 26 as
> answer... :-/
Using: OPEN"I",#1,"PPPP" generates an error as expected. Interestingly
enough, the ERNO and ERLIN values are only set if an ONERR is in effect.
Also, removing the ONERR yields the expected ?NE ERROR IN 20 message.
The upshot of all this is that the handler must be running as there is
no code path that would abort that process once it starts. A little
examination of the code brought me to the following discovery:
LOAD sets the DEVNUM value to 1 greater than the number of the reserved
files for Disk Basic. It does this *BEFORE* it even attempts to open the
file. Unfortunately, it does not get reset to 0 before the NE error is
thrown and the ONERR handling code does not reset anything when it fires
the handler. In MOST cases, this is the correct result. In the case of
LOAD, it isn't.
If the example program is changed to:
It will, indeed, print out the expected results.
It should be noted that if LOAD throws an AO error, the same result
It is interesting to note that if "CLOAD" throws an error while reading
data blocks from an ASCII file, the exact same situation should occur
but this time with -1 in DEVNUM. (Assuming I read the CLOAD code right.)
It should be noted that the FIRST PRINT statement will try to send its
output to the bogus DEVNUM value but subsequent ones will operate as
> William Astle wrote:
>> Diego Barizo wrote:
>>> While debugging a program, I noticed that some errors just don't
>>> generate an error code, like "NE error"
>>> Is there anywhere I could "peek" to identify this error?
>>> And out of curiosity, does anyone know why some errors are not included?
>>> ( I seen to remember another error that did not generate an error code,
>>> but just can't remember which one)
>> I thought NE was error code 26 (Unravelled book confirms.) Interestingly
>> enough, NE is defined by Extended Basic even though most folks would
>> only encounter it when using Disk Basic.
>> Unless you're doing something odd, all errors go through the same
>> handling process so ERRNO should provide the error code (assuming ON ERR
>> GOTO in effect). The only special handling I see in the error routines
>> is for some weird case of a UL error. (Note that if you aren't doing ON
>> ERR GOTO, you won't get the error code stored anywhere.)
finger lost at l-w.ca for further information
Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w---
!D !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?
More information about the Coco