-
Notifications
You must be signed in to change notification settings - Fork 333
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
A way to avoid panic on drop behavior? #1292
Comments
Just for reference, rust-postgres doesn't panic. Rusqlite doesn't provide any binding (yet) to sqlite3_trace_v2 but users can use SQLITE_TRACE_CLOSE to trap close event.
Rust is not gced and, afaik, the order of destructors is deterministic. |
I think it's reasonable for us to not panic on drop ever. In general that behavior is pretty discouraged now in the standard library, which probably we should follow. |
Yeah, I did read that But thanks, I'll put up a trivial PR to just not panic on drop. |
Hi,
We are using rusqlite (indirectly) behind an
Arc<>
in a context wherepanic=abort
(desktop Firefox). As a result, becauseclose()
consumesself
, we can't absolutely guarantee that at shutdown time we canArc::try_unwrap()
to get ownership of the connection to callclose()
on andmem::forget
it on failure. This means there's a chance that as the app shuts down the app will abort as it is dropped. We'd much rather leak the connection than abort.I assume the panic is desirable in some use-cases, otherwise I'd suggest that on drop rusqlite either ignores the error or uses
sqlite_close_v2
. I'm not sure in which contexts it would actually be desirable though - if consumers really want to notice the error they still have the explicit close available.Alternatively, maybe a new boolean could be introduced 👋 somewhere 👋 to control this behavior?
Either way, I'd be happy to put a PR up once I know what approach, if any, would be likely to be accepted.
The text was updated successfully, but these errors were encountered: