#29257: If creation of a db cursor fails, the resulting traceback is misleading
-------------------------------------+-------------------------------------
Reporter: Jerome Leclanche | Owner: (none)
Type: Bug | Status: new
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jacob Walls):
Thanks for digging in! (Also please ignore my rough test in comment:5;
there are better tests in the [https://github.com/django/django/pull/8372
pull request for django 1.11].) Some more related tickets I found:
The cursor close exception was intentionally masked in Django 1.11
(6b6be692fcd102436c7abef1d7b3fa1d37ad4bdf) because Python 2 did not chain
exceptions -- with a note that in Python 3, the default exception chaining
would either be superior to masking or at least not worth maintaining a
workaround. This fix was adjusted in #28091.
Then on the python 3 upgrade, this was removed as promised in
d170c63351944fd91b2206d10f89e7ff75b53b76.
Then this ticket was accepted, which goes the other way.
Then a dupe of this ticket was closed as needsinfo: #33331, with the
latest response in ticket:33331#comment:11 being:
> You're then asking for a change in behaviour to remove information from
the traceback. Maybe that's OK if there's a good reason, but otherwise the
presumption would be wontfix.
My 2ยข, we have multiple reports finding this confusing, and I do see this
in my dev workflow from time to time. An ugly message about cursors is too
much noise for beginners. So I think we could consider masking the cursor
close exception as proposed in #33331.
> In practice, cursor closure can fail for many reasons, and seeing the
original exception with full traceback is often more helpful than hiding
it behind secondary issues.
I follow in the general case, but do you have a view on whether here,
inside exception handling, the cursor failure info would be relevant? (I'm
struggling to see why it would be anything but noise.)
--
Ticket URL: <https://code.djangoproject.com/ticket/29257#comment:8>
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 visit
https://groups.google.com/d/msgid/django-updates/01070196d3effbf8-ca4b71bd-6533-4df7-a646-c3df7cccf3bc-000000%40eu-central-1.amazonses.com.
