Not found error

[Tony van der Hoff]

On 12 Jan 2003, in message <ae39abb34b.Jan-Jaap at c2i.net>,
Jan-Jaap van der Geer <janjaap at dsv.nl> wrote:

> Hi,
> 
> I'd like to check for an error that accurs when you for example do:
> 
> *create SomeDirThatDoesntExist.File
> 
> You'll get a "Not found" error (&117D6). I'm not really sure how
> I'll find the correct constant to use for that. I'm now searching
> in the stronghelp page for OSLib, and I find these:
> 
[snip]
> 
> error_NOT_FOUND 0x424
> 
> That's not it I guess. However, in the description (in StrongHelp),
> it says: "Not found, &0100D6", again the last byte correct...?!
> 
I don't understand the "&0100D6" bit; I don't think it's even a valid code,
and suspect it is an artifact from some earlier definition, so unless anyone
else here knows what it means, I'll change the comment line to "File not
found"; thanks for pointing that one out.

> Is the error just not defined? Is there a better way of finding a
> match between the error and the constant defined for it in OSLib?
> 
I would use Steve Fryatt's !Locate utility to search the OSLib.h directory
for the number. In this case (0x117D6) appears to be not defined in OSLib,
not surprisingly, if you read on...

The error codes in RISC OS are, IMHO, a mess, but it's what we're stuck
with. If you refer to the PRM (1-42), you'll see that the low byte is a
'basic error number'; the middle two bytes indicate which part of the OS
generated the error; and the top byte contains flags.

In the case of 0x424, this indicates error 24 from FileSwitch, which is
defined in fileswitch.h as error_NOT_FOUND. I guess this indicates
that FileSwitch was unable to find a given FS. Naively I would have expected
this to be 0x4D6, but no...

However, in the case of the 01XXYY group, XX indicates the filing system
number. FS 0x17 is defined (in ileswitch.h) to be RAMFS, so 117D6 is "File
not found in RAMFS".

OSLib does its best to define (in os.h) all the basic 0XX error numbers;
and does quite a good job of defining the XXX error codes, but beyond that it
gets a bit lost, because of the profusion of error codes, most of which don't
appear in the documentation.

Depending upon what you're trying to achieve you'll need to programmatically
break down the returned error code, and analyse it appropriately. I would
have hoped for an OS routine to handle this, but, again, no...

HTH, Tony

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk