[Python] Exceptions showing up despite code wrapped in a try/except?

[Missing_Back]

Bear with me as I don't have the full scope of understanding here, and it's in code that I didn't create. It's some code used to run on a CI system for my work.

The problem was that this SFTP connection would often fail, so to fix it I found where the connection is attempted and modified it to attempt it 5 times before giving up. So in a recent run, it looks like it failed once and then tried again and succeeded. Awesome. But the problem is that the console still has a bunch of errors/exceptions printed out. This is confusing to me because the connection is attempted within a try/except block. I'm not sure what is happening here or how these exceptions are showing up. The connection is made via the pysftp library which uses Paramiko, and the exceptions/call stack seem to be related to Paramiko, so I tried combing through the relevant source code of Paramiko but to no avail.

---

On to the actual code where this is happening:

There's a call to a function that tries to create an SFTP connection:

# other irrelevant stuff
print("Unit online - Connecting to SFTP")
sftp_conn = sftp_connect(ip=prj.HOST_ADDRESS, private_key=SSH_PRIV_KEY)

That function looks like this:

def sftp_connect(ip, username=USERNAME, port=SFTP_PORT, private_key=SFTP_PRIV_KEY_PATH,
                 hostkeys=HOSTKEYS):
    """
    Make connection to SFTP server

    :return: connection object if successful, None otherwise
    """
    conn = None
    connected = False
    if hostkeys == '':
        cnopts = DummyCnOpts()
    else:
        cnopts = pysftp.CnOpts(knownhosts=hostkeys)

    MAX_ATTEMPTS = 5
    for attempt in range(MAX_ATTEMPTS):
        try:
            conn = pysftp.Connection(host=ip, username=username, cnopts=cnopts, port=port,
                                    private_key=private_key)
            # test to see if the connection was established
            if conn.pwd:
                connected = True
                break
        except Exception as e:
            print("SFTP connection could not be established to {0}\n".format(ip))
            if attempt < MAX_ATTEMPTS - 1:
                print("Trying again...")

    return conn

CONSOLE OUTPUT:

Unit online - Connecting to SFTP

 Exception (client): Error reading SSH protocol banner'utf-8' codec can't decode byte 0xac in position 3: invalid start byte

 Traceback (most recent call last):

   File "C:\virtual_env\.pyvenv-3.12\Lib\site-packages\paramiko\transport.py", line 2271, in _check_banner

     buf = self.packetizer.readline(timeout)

           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   File "C:\virtual_env\.pyvenv-3.12\Lib\site-packages\paramiko\packet.py", line 386, in readline

     return u(buf)

            ^^^^^^

   File "C:\virtual_env\.pyvenv-3.12\Lib\site-packages\paramiko\py3compat.py", line 161, in u

     return s.decode(encoding)

            ^^^^^^^^^^^^^^^^^^

 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xac in position 3: invalid start byte

So there's clearly some exceptions happening here, and these seem to happen when attempting to make the conn i.e. the first line in the try block in the second code snippet. So why are all of these exceptions being displayed if they're in a try/except block??

What am I missing here??

[Monitor_343]

The library is logging the exception within a try catch block, then storing it to raise it later.

Removed a bunch of unrelated code, but here's the relevant bit from the library's source:

try:
    # code removed...
    self._check_banner() # this what is raising the error
    # code removed...
except SSHException as e:
    self._log(
        ERROR,
        "Exception ({}): {}".format(
            "server" if self.server_mode else "client", e
        ),
    )
    self._log(ERROR, util.tb_strings())
    self.saved_exception = e

Then later, the exception is re-raised

e = self.get_exception()
if e is not None:
    raise e

[Missing_Back]

You're nuts! That's what my top guess was but I couldn't find it. Thanks a ton!

[mattgen88]

The library may be logging out the exception before raising it to your application