engine/base -> safe_close_cursor assumes our connection has a _logger

Issue #3063 resolved
Mike Bayer repo owner created an issue

it's very tough to figure out how to reproduce this one. If you get a non-disconnect exception, but an unclosable cursor within first connect, the exception is squashed because we have a DBAPI connection in first_connect, not a connection fairy.

    def _safe_close_cursor(self, cursor):
        """Close the given cursor, catching exceptions
        and turning into log warnings.

        """
        try:
            cursor.close()
        except (SystemExit, KeyboardInterrupt):
            raise
        except Exception:
            self.connection._logger.error(
                                    "Error closing cursor", exc_info=True)

Comments (2)

  1. Mike Bayer reporter
    • vastly improve the "safe close cursor" tests in test_reconnect
    • Fixed bug which would occur if a DBAPI exception occurs when the engine first connects and does its initial checks, and the exception is not a disconnect exception, yet the cursor raises an error when we try to close it. In this case the real exception would be quashed as we tried to log the cursor close exception via the connection pool and failed, as we were trying to access the pool's logger in a way that is inappropriate in this very specific scenario. fixes #3063

    → <<cset 814637e29195>>

  2. Mike Bayer reporter
    • vastly improve the "safe close cursor" tests in test_reconnect
    • Fixed bug which would occur if a DBAPI exception occurs when the engine first connects and does its initial checks, and the exception is not a disconnect exception, yet the cursor raises an error when we try to close it. In this case the real exception would be quashed as we tried to log the cursor close exception via the connection pool and failed, as we were trying to access the pool's logger in a way that is inappropriate in this very specific scenario. fixes #3063

    → <<cset 758dc17f4fd0>>

  3. Log in to comment