From: Tommi Virtanen <tv@twistedmatrix.com> Subject: Re: [Twisted-Python] Proposal: changes to reactor.clientTCP Date: 21 Jun 2002 22:04:08 +0300
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.
Upon consideration I strongly agree that no information should be lost. So, let's have such a high-level error, and a .platformError attribute on the connection error object which is an object specific to the "OS" that you're running under. On POSIX this will be (or contain) an errno error code, but on Jython and elsewhere it will be whatever's appropriate. Does that work for you?
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.
The reason I'm resistent to this is that I would like to encourage writing portable programs with Twisted, especially in cases where platform specificity doesn't add any functionality. On the other hand, I don't want to be Java here and try to _force_ programmers to write their programmers in a portable way when they really know better than I do what they want. Problem is, programmers rarely know what they want. For example; if you're using Twisted, why use fork? You ought to be using reactor.spawnProcess for non-portability-related reasons anyway; Python's refcounting doesn't work reliably with COW memory. Of course, there are reasons not to do this; of course, there are times when you just _need_ to get down to the OS and do something in a very, very platform specific way (sometimes even specific to your particular OS vendor, not just POSIX). This should not be the default. Handling an errno error code specifically should also be considered a *very* esoteric operation. I personally can't come up with any need to use it except debugging under a particular environment; I would far rather that people used to the POSIX API learned how to use the Twisted APIs to do POSIX-y things, so that their programs would be more portable. Balancing this with the need not to piss people off is difficult :-). I can't think of a way to say "DON'T USE .platformError UNLESS YOU REALLY NEED IT, WHICH YOU DON'T" without making everybody read the documentation, which they won't anyway. I can imagine many programs made non-portable by someone looking for the answer to the question "how do I find the errno of what happened" rather than the correct question "how do I handle a connection error". So I guess I'll provide the platform specific information and put my faith in the worldview of applications programmers; please try to give them good examples to look at :) -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |