#15901: Django should wrap all PEP 249 exceptions in db.utils
-------------------------------------+-------------------------------------
Reporter: xiaket | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 1.3
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by jamesh):
Both of your suggestions prevent users from writing standard Python
"except" clauses to catch particular classes of database errors, which
seems to be one of the goals of this ticket.
And for some database adapters like psycopg2, there is more useful
information in the exception than you'll find in `e.args` (e.g. the
`pgcode` attribute holding the SQL error code).
If your concern is about not being able to distinguish exceptions that
come directly from the database adapter and exceptions from the Django
backend, what do you see as the consequences of not being able to do this?
Django used to let the adapter exceptions bubble up through the backends.
It only changed when support for multiple databases were added and it was
necessary to have some backend independent exceptions to catch. If we let
the adapter exceptions bubble up but keep the ability to catch backend
independent exceptions, what do we lose?
--
Ticket URL: <https://code.djangoproject.com/ticket/15901#comment:12>
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.
