#15901: Django should wrap all PEP 249 exceptions in db.utils
-------------------------------------+-------------------------------------
Reporter: xiaket | Owner: nobody
Type: New | Status: new
feature | Component: Database layer
Milestone: | (models, ORM)
Version: 1.3 | Severity: Normal
Resolution: | Keywords:
Triage Stage: Design | Has patch: 0
decision needed | Needs tests: 0
Needs documentation: 0 | Easy pickings: 0
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by mtredinnick):
* ui_ux: => 0
* stage: Accepted => Design decision needed
Comment:
We have intentionally and very deliberately not done this to date, because
the exception types vary across the various database backends. Even when
they offer the standard PEP 249 exceptions, their contents cannot be
treated portably because they are often implemented quite differently.
Wanting to handle arbitrary exceptions from an unknown database is a very
big ask for application code and, as I said, we decided not to support
this use-case. We expose the two, including the base class, that are most
commonly going to be raised to the user level.
More useful for practical purposes would be an explanation of what the big
use-cases are that need particular exceptions exposed. Remember that once
Django adds support for something like this, we have to support it
**forever**, so it's not to be done lightly.
--
Ticket URL: <https://code.djangoproject.com/ticket/15901#comment:4>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
