Glyph Lefkowitz <glyph@twistedmatrix.com> writes:
Please do not clobber the information given by the kernel in errno. Translating errno to 2 different failures is not nice.
It needs to be clobbered, at least in some sense, for portability.
Jython does not have errno and win32's support for it is very weak.
Reading this a few hours later, I think my tone was wrong and I was altogether too brief here. :-). To rephrase in a more constructive manner:
I believe that it needs to be clobbered, and some information lost, because I don't see any other way to retain portability. Also, we're losing information already, since errno is used to report things that aren't "errors" in the Twisted worldview (or at least, not errors that the user can deal with directly). Jython and win32 both have error-reporting mechanisms; Jython's is exceptions, win32 is a sort of wacked-out informal errno. Can you think of a few primitive errors that we should support, rather than just the 2 types? (I'd rather use Failure than just integer error codes, personally.)
I think that if we're going to add a new error reporting mechanism we need to do it carefully so that we don't miss the same kind of information that we did the last time we architected this API. (Protocol.connectionLost used to take an integer error code which was one of these two errors; that was a bad idea, too).
Thanks for your feedback. Does anybody have a solution?
Allow portable programs to get a "sanitized version", but allow my POSIX-only programs get errno. For what kind of sanitization one might want, you probably want to look at the man page for say connect(2) for all the possible error cases, and categorize them based on local/remote, temporary/permanent, etc., and create a "high-level error" for each class, with perhaps the string corresponding to the errno as extra info meant for users (and not if statements). But please do _not_ loose any information in the translation. Say people shouldn't look at the error objects errno attribute to decide what to do, as not all platforms provide it. But don't hide the actual error. Remember my background; I'm a kernel hacker, and I know the UNIX libc/kernel API. If I run a program that tries to e.g. connect with TCP, and it fails without giving me a good reason, I _will_ run it under strace -e trace=connect just to see whether connect failed, and with what errno. Operating systems without BSD sockets just aren't, and I write my programs to use fork anyway. My point -- don't decide for me, let me decide on my own. -- tv@{{hq.yok.utu,havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com} double a,b=4,c;main(){for(;++a<2e6;c-=(b=-b)/a++);printf("%f\n",c);}