#33331: Improve exception handling with `cursor.close()` after errors
-------------------------------------+-------------------------------------
Reporter: Daniel Hahler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: 3.2
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Daniel Hahler):
Sorry for not having read the mailing list thread yet, but only your
summary of it above.
I think the main issue with context vs. cause is an important detail. I
can see that it might not worth changing it all over the code base, but it
should be considered when fixing code.
The main issue I see here is that there will be an exception almost always
(at least with named cursors in PostgreSQL AFAICS), and therefore it
should not even be chained in this case: it really just hides the actual
error, just because it is trying to ensure a (never properly opened/used)
cursor is closed always.
I might follow up on the mailing list, but do not really feel like
subscribing there also etc, especially since the issue here is not about
context or cause, but only using `raise from` properly (according to
https://blog.ram.rachum.com/post/621791438475296768/improving-python-
exception-chaining-with) when not swallowing/hiding the expected
exception.
--
Ticket URL: <https://code.djangoproject.com/ticket/33331#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.74c47913aeea05683a575dc75e8abf8c%40djangoproject.com.
