Re: Undefined Errno::EPROTO and the like raises NameError

Quoting [e-mail], on Tue, Mar 08, 2005 at 10:03:16AM +0900:
> Hi,
> 
> In message "Re: Undefined Errno::EPROTO and the like raises NameError"
>     on Tue, 8 Mar 2005 01:17:37 +0900, "Florian Frank" <[e-mail]> writes:
> 
> |I just run into the problem, that certain System Call Errors aren't 
> |defined depending on the platform. I tested on a platform, where 
> |Errno::EPROTO is not defined. If I code something like
> 
> Yeah, it's on my to-do list for a long time, but without any idea to
> solve.  Errno exceptions vary platform to platform, so that simple
> scripts like you did cause NameError, but I don't want to allow
> reference to undefined constants in the rescue clause, since relaxing
> constant reference here changes the meaning of expression, and makes
> semantics more complex.  Any idea?

I used to think like Florian, but now I think it is better the way it is
right now.

It seems like it makes it hard to be cross platform, but in a way it
makes it easier. If you have


  rescue Errno:EPROTO
    ...

and expect it to do something, and then run it on a platform that uses a
different errno than EPROTO for the condition, your code will silently
"seem" to work, but actually it works wrongly. For example, I just
looked and there is no EPROTO I see for Mac OS X, so I don't know what
it means, it must be a different error number on OS X.

It is better for your code to fail, then you will look at the man page
and realize that on this platform you need to rescue a different errno.

Another example is setting socket option REUSEPORT. It doesn't exist on
all platforms, and on the ones it doesn't, you need to set a different
socket option. If socket.c defined SOREUSEPORT, crazy things would
happen, but not what you wanted!

I think error numbers shouldn't be different from the other OS-specific
constants, like those in socket.c.

Cheers,
Sam