Paramiko throws EOFError rather than returning a 0 length file or ENOENT

Vincent Ladeuil v.ladeuil at alplog.fr
Tue Sep 12 08:33:27 BST 2006


>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:

    jam> Robey Pointer wrote:
    >> 

    jam> ...

    >>>> bzr is 0.9-0ubuntu2, the rest of the system is up-to-date edgy.
    >>> 
    >>> Looks to me like paramiko is being unfriendly here. We
    >>> should probably catch this and turn it into either ENOENT
    >>> or a 0 length file, depending on what Robey says is
    >>> happening.
    >>> 
    >>> affects /products/bzr
    >> 
    >> It looks like the underlying server connection vanished.
    >> I should translate that into an SSHException for the next
    >> version, but I'm not sure if that should be treated as
    >> ENOENT or an empty file.  It probably should just be
    >> treated as a "fail" error and let the user retry.  (In
    >> other words, same as now, but without the stack trace.) ;)
    >> 
    >> robey


    jam> Well if the connection goes away, then we would probably
    jam> prefer to translate it into ConnectionError on our end.
    jam> The problem is that this is happening at 'read()' time,
    jam> not at 'get()' time. So it can't be wrapped by the
    jam> transport.  Either the transport needs to return a
    jam> wrapped file object, that translates read() exceptions,
    jam> or the bzr core needs to start understanding transport
    jam> specific errors.

    jam> So this may be a reason to introduce a TransportFile,
    jam> which is file-like, only it handles translating a
    jam> transport specific exception into a generic exception.

http faces the same kind of problem, the reads can (today for
pycurl, in the future for urllib) occur outside the scope of the
transport, so having a TransportFile, if not necessary now, can
solve future problems.

+1 on the concept

   Vincent





More information about the bazaar mailing list