Skip to content
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

Cannot Open after Dispose #331

Closed
bgrainger opened this issue Sep 21, 2017 · 3 comments
Closed

Cannot Open after Dispose #331

bgrainger opened this issue Sep 21, 2017 · 3 comments

Comments

@bgrainger
Copy link
Member

Connector/NET allows the following code:

var connection = new MySqlConnection("connection string");
connection.Open();
connection.Dispose();
connection.Open();

MySqlConnector throws an ObjectDisposedException on the last line.

In practice, this could happen if a MySqlConnection object was captured by a lambda inside a using block, then invoked after the connection is disposed.

@ejball
Copy link
Contributor

ejball commented Sep 21, 2017

IMHO, the current behavior is correct and superior; the Connector/NET behavior could mask bugs.

If someone really wants the Connector/NET behavior, e.g. because they don't want to fix legacy code, perhaps we should add (yet) another connection setting?

@NateMerritt
Copy link

I also agree that MySqlConnector has correct behavior over Connector/NET. This might be something to mention in the migration docs; I don't know if it's worth "fixing" or adding a new connection setting.

@bgrainger
Copy link
Member Author

FWIW, SqlConnection.Dispose() has the side-effect of clearing the connection string, so this "pattern" doesn't work with it. (It won't throw ObjectDisposedException, but Open will throw InvalidOperationException: The ConnectionString property has not been initialized.)

I haven't tested Npgsql, but NpgsqlConnection.Open calls Open(...) which calls CheckConnectionClosed which calls CheckDisposed which throws if _disposed is true, and that is set in Dispose. So it appears this wouldn't work with Npgsql either.

I think updating the documentation is the correct approach here.

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

No branches or pull requests

3 participants