[Twisted-Python] newbie question: error handling
glyph at twistedmatrix.com
Mon Dec 31 20:14:38 EST 2001
On Mon, 2001-12-31 at 12:27, Ivo van der Wijk wrote:
> > > How can I determine what specific error condition caused connectionLost()
> > > or connectionFailed()? I.e. connection refused, unknown hostname,
> > > no route to host, etc (the standard errno stuff).
> > Currently you can't. [snip]
> Okay. How about an error parameter to connectionLost|Failed
> that would contain the actual error? [snip]
This was the way Twisted originally worked; we wrote a TON of code and
this parameter was never used :-). Feel free to add it, though; your
connectionFailedWithError approach sounded like a good one.
> > > Also, how can I determine if Linereceived.sendLine() (or
> > > Protocol.Transport.write()) failed? It doesn't seem to return an
> > > error value or raise Exceptions, and depending on the invocation
> > > of connectionLost makes things perhaps too asynchronous..
> > If you need this level of guarantee, you need a protocol which will send
> > acks for messages as they've been received. There is no such thing as
> > "too asynchronous" -- there is "synchronous", "asynchronous", and
> > "sometimes stuck doing something with one client while the rest of the
> > server hangs..." :-).
> Well, you could return an error if the connection is obviously closed
> already (and perhaps return the error received when the connection was
> close asynchronously) - i.e. when it's clear that the async. write will
> fail. The rest can be handled right away. [snip]
I *could*, but why would I? This means that your errors have to be
handled in two places instead of one, and it will only *sometimes*
actually be handled by one of those two places, depending on the OS
buffer sizes and the direction of prevailing winds.
There are lots of places where a connection can be dropped, and there
are lots of reasons for it. Unifying them into a single "connection has
been lost" failure path is in general a good thing; I could understand
wanting more information about that failure (your previous request) but
wanting the failure case to be exposed to your code through numerous
paths -- all of which must be handled and the distinction between which
is VERY difficult to test -- seems like a naive regression to a
> > Keep in mind that a write "succeeding" might just mean that the memory
> > was succesfully copied into a buffer for your OS kernel to send; the
> > other side of the connection may never have received it.
> I basically meant succeeding as with socket.recv/send().
Why is this useful information to have at the application layer?
______ you are in a maze of twisted little applications, all
| |_\ remarkably consistent.
| | -- glyph lefkowitz, glyph @ twisted matrix . com
More information about the Twisted-Python