I guess my point was more the fact that we should come up with a standard error list that can be returned from a set primitive. What they are called I don't really care, I just used the POSIX example as... well... an example :)
However I do think that a lot of the POSIX error symbols can be used even though many APIs are called. For example #ECONNREFUSED could be returned from a socket open primitive and even though you have no idea/don't care what the primitive is doing internally; it is pretty obvious what the error means.
The main thing would be to "standardise" the interfaces between Squeak and primitives to MINIMISE the amount of platform specific code in very crucial parts of the kernel. I don't think it is hard to do; I think the problem is that very few people are willing to touch the guts and so we are left with the status quo which is getting old and hairy.
Russell
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Ned Konz Sent: Monday, 30 August 2004 1:19 AM To: The general-purpose Squeak developers list Cc: David T. Lewis Subject: Re: functionality of Socket>>socketError
On Sunday 29 August 2004 6:43 am, David T. Lewis wrote:
Why not have the primitives return a symbol which is a POSIX error
name?
We have a list of codes that can be returned from the Socket
primitives
and each platform VM is coded to that standard. Then you don't need to know what error code on each platform is, the code in the Squeak side
is
standard and you don't need a platform mapping class. Plus people who know POSIX stuff :) can at least make some sense of
what
is going wrong.
But yes, I agree that your suggestion here might be a simpler approach
for
reporting socket errors. (I'm no expert on POSIX sockets, so I don't
know
if this is workable across a range of platforms.)
That doesn't fix the problem that you get when your primitive calls several API calls, each of which can return roughly the same set of errors.
In cases like that you'd either have to:
- pass back the *first* error code and let people guess what it meant
(i.e. what API call generated it), or
- generate a new error code that names a particular error condition
- include more context (like for instance what the API call was that
generated the error)
-- Ned Konz http://bike-nomad.com/squeak/