[Coco] Error codes on SECB

[William Astle]

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:

10 ONERRGOTO1000
20 LOAD"PPPP"
30 STOP
1000 PRINT#0,ERNO,ERLIN

It will, indeed, print out the expected results.

It should be noted that if LOAD throws an AO error, the same result 
would occur.

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 
expected.

> 
> 
> 
> 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.)
>>
>>   
> 
> 


-- 
William Astle
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?