Skip to content

change in exception object for closed connection use, was buggy before and should be improved #202

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zzzeek opened this issue Sep 1, 2017 · 5 comments · Fixed by #203
Closed

Comments

@zzzeek
Copy link

zzzeek commented Sep 1, 2017

Just saw my builds failing on mysqlclient, and sure enough new release sep 1 today.

This is not really a new "bug", but it is a change in behavior in an area that is already IMO kind of a bug, so if it's being changed, might as well make it nicer. The change in this exeption will mean I have to put out new releases f SQLAlchemy to accommodate for it (I'm putting out new releases all the time anyway), just want to make sure you intended this. IMO it should either stay the way it was exactly (if that was the intent), or probably should be made nicer if it is changing:

import MySQLdb

conn = MySQLdb.connect(user='scott', passwd='tiger', host='localhost', db='test')
cursor = conn.cursor()
conn.close()

try:
    cursor.execute("select 1")
except Exception as e:
    print(MySQLdb.__version__)
    print(repr(e))


with 1.3.7 we get:

1.3.7
InterfaceError(0, '')

with 1.3.11:

1.3.11
InternalError(0, '')

If we're going to change from InterfaceError to InternalError, you might as well put a message describing what's going on when this is raised (e.g. "connection was closed, you can't use this cursor now").

@methane
Copy link
Member

methane commented Sep 1, 2017

No, It's not intended.
I think it's side effect of 1a10d0e.

I don't have any idea about what is the right exception to raise.

@methane
Copy link
Member

methane commented Sep 1, 2017

I'll revert this unintentional change soon.

@methane
Copy link
Member

methane commented Sep 1, 2017

@zzzeek Do you know what is the common error type for querying to closed connection?
ProgrammingError? InterfaceError? or InternalError?

@methane methane reopened this Sep 1, 2017
@zzzeek
Copy link
Author

zzzeek commented Sep 1, 2017

everyone does something different and arbitrary. Looking at https://www.python.org/dev/peps/pep-0249/, OperationalError specifically is for an "unexpected disconnect". I guess in this case we don't consider the "disconnect" to be unexpected, though it is possible that I have this error in the disconnect list because it was observed without someone necessarily calling .close(), but I'm not sure.

For this case, it's still vague what should be used, it mentioned InternalError for "cursor not valid anymore". I sort of like InterfaceError more because "InternalError" makes it sound like this is an internal bug in the driver. ProgrammingError is really more about the content of the SQL being sent and all that, I think.

psycopg2 uses InterfaceError(). So, I like that.

@methane
Copy link
Member

methane commented Sep 1, 2017

OK, I released 1.3.12 which revert the change just now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants