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 at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at 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/