mirror of
https://github.com/django/django.git
synced 2024-12-25 02:26:12 +00:00
59a3520875
Squashed commit of the following:
commit 2181d833ed1a2e422494738dcef311164c4e097e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Wed Feb 27 14:28:39 2013 +0100
Fixed #15901 -- Wrapped all PEP-249 exceptions.
commit 5476a5d93c19aa2f928c497d39ce6e33f52694e2
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:26:52 2013 +0100
Added PEP 3134 exception chaining.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 9365fad0a650328002fb424457d675a273c95802
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:13:49 2013 +0100
Improved API for wrapping database errors.
Thanks Alex Gaynor for the proposal.
commit 1b463b765f2826f73a8d9266795cd5da4f8d5e9e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 15:00:39 2013 +0100
Removed redundant exception wrapping.
This is now taken care of by the cursor wrapper.
commit 524bc7345a724bf526bdd2dd1bcf5ede67d6bb5c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:55:10 2013 +0100
Wrapped database exceptions in the base backend.
This covers the most common PEP-249 APIs:
- Connection APIs: close(), commit(), rollback(), cursor()
- Cursor APIs: callproc(), close(), execute(), executemany(),
fetchone(), fetchmany(), fetchall(), nextset().
Fixed #19920.
commit a66746bb5f0839f35543222787fce3b6a0d0a3ea
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:53:34 2013 +0100
Added a wrap_database_exception context manager and decorator.
It re-throws backend-specific exceptions using Django's common wrappers.
176 lines
5.5 KiB
Plaintext
176 lines
5.5 KiB
Plaintext
=================
|
|
Django Exceptions
|
|
=================
|
|
|
|
|
|
Django raises some Django specific exceptions as well as many standard
|
|
Python exceptions.
|
|
|
|
Django-specific Exceptions
|
|
==========================
|
|
|
|
.. module:: django.core.exceptions
|
|
:synopsis: Django specific exceptions
|
|
|
|
ObjectDoesNotExist and DoesNotExist
|
|
-----------------------------------
|
|
.. exception:: DoesNotExist
|
|
.. exception:: ObjectDoesNotExist
|
|
|
|
The :exc:`DoesNotExist` exception is raised when an object is not found
|
|
for the given parameters of a query.
|
|
|
|
:exc:`ObjectDoesNotExist` is defined in :mod:`django.core.exceptions`.
|
|
:exc:`DoesNotExist` is a subclass of the base :exc:`ObjectDoesNotExist`
|
|
exception that is provided on every model class as a way of
|
|
identifying the specific type of object that could not be found.
|
|
|
|
See :meth:`~django.db.models.query.QuerySet.get()` for further information
|
|
on :exc:`ObjectDoesNotExist` and :exc:`DoesNotExist`.
|
|
|
|
MultipleObjectsReturned
|
|
-----------------------
|
|
.. exception:: MultipleObjectsReturned
|
|
|
|
The :exc:`MultipleObjectsReturned` exception is raised by a query if only
|
|
one object is expected, but multiple objects are returned. A base version
|
|
of this exception is provided in :mod:`django.core.exceptions`; each model
|
|
class contains a subclassed version that can be used to identify the
|
|
specific object type that has returned multiple objects.
|
|
|
|
See :meth:`~django.db.models.query.QuerySet.get()` for further information.
|
|
|
|
SuspiciousOperation
|
|
-------------------
|
|
.. exception:: SuspiciousOperation
|
|
|
|
The :exc:`SuspiciousOperation` exception is raised when a user has performed
|
|
an operation that should be considered suspicious from a security perspective,
|
|
such as tampering with a session cookie.
|
|
|
|
PermissionDenied
|
|
----------------
|
|
.. exception:: PermissionDenied
|
|
|
|
The :exc:`PermissionDenied` exception is raised when a user does not have
|
|
permission to perform the action requested.
|
|
|
|
ViewDoesNotExist
|
|
----------------
|
|
.. exception:: ViewDoesNotExist
|
|
|
|
The :exc:`ViewDoesNotExist` exception is raised by
|
|
:mod:`django.core.urlresolvers` when a requested view does not exist.
|
|
|
|
MiddlewareNotUsed
|
|
-----------------
|
|
.. exception:: MiddlewareNotUsed
|
|
|
|
The :exc:`MiddlewareNotUsed` exception is raised when a middleware is not
|
|
used in the server configuration.
|
|
|
|
ImproperlyConfigured
|
|
--------------------
|
|
.. exception:: ImproperlyConfigured
|
|
|
|
The :exc:`ImproperlyConfigured` exception is raised when Django is
|
|
somehow improperly configured -- for example, if a value in ``settings.py``
|
|
is incorrect or unparseable.
|
|
|
|
FieldError
|
|
----------
|
|
.. exception:: FieldError
|
|
|
|
The :exc:`FieldError` exception is raised when there is a problem with a
|
|
model field. This can happen for several reasons:
|
|
|
|
- A field in a model clashes with a field of the same name from an
|
|
abstract base class
|
|
- An infinite loop is caused by ordering
|
|
- A keyword cannot be parsed from the filter parameters
|
|
- A field cannot be determined from a keyword in the query
|
|
parameters
|
|
- A join is not permitted on the specified field
|
|
- A field name is invalid
|
|
- A query contains invalid order_by arguments
|
|
|
|
ValidationError
|
|
---------------
|
|
.. exception:: ValidationError
|
|
|
|
The :exc:`ValidationError` exception is raised when data fails form or
|
|
model field validation. For more information about validation, see
|
|
:doc:`Form and Field Validation </ref/forms/validation>`,
|
|
:ref:`Model Field Validation <validating-objects>` and the
|
|
:doc:`Validator Reference </ref/validators>`.
|
|
|
|
.. currentmodule:: django.core.urlresolvers
|
|
|
|
NoReverseMatch
|
|
--------------
|
|
.. exception:: NoReverseMatch
|
|
|
|
The :exc:`NoReverseMatch` exception is raised by
|
|
:mod:`django.core.urlresolvers` when a matching URL in your URLconf
|
|
cannot be identified based on the parameters supplied.
|
|
|
|
.. currentmodule:: django.db
|
|
|
|
Database Exceptions
|
|
===================
|
|
|
|
Django wraps the standard database exceptions so that your Django code has a
|
|
guaranteed common implementation of these classes. These database exceptions
|
|
are provided in :mod:`django.db`.
|
|
|
|
.. exception:: Error
|
|
.. exception:: InterfaceError
|
|
.. exception:: DatabaseError
|
|
.. exception:: DataError
|
|
.. exception:: OperationalError
|
|
.. exception:: IntegrityError
|
|
.. exception:: InternalError
|
|
.. exception:: ProgrammingError
|
|
.. exception:: NotSupportedError
|
|
|
|
The Django wrappers for database exceptions behave exactly the same as
|
|
the underlying database exceptions. See :pep:`249`, the Python Database API
|
|
Specification v2.0, for further information.
|
|
|
|
.. versionchanged:: 1.6
|
|
Previous version of Django only wrapped ``DatabaseError`` and
|
|
``IntegrityError``.
|
|
|
|
.. exception:: models.ProtectedError
|
|
|
|
Raised to prevent deletion of referenced objects when using
|
|
:attr:`django.db.models.PROTECT`. Subclass of :exc:`IntegrityError`.
|
|
|
|
.. currentmodule:: django.http
|
|
|
|
Http Exceptions
|
|
===============
|
|
|
|
.. exception:: UnreadablePostError
|
|
|
|
The :exc:`UnreadablePostError` is raised when a user cancels an upload.
|
|
It is available from :mod:`django.http`.
|
|
|
|
.. currentmodule:: django.db.transaction
|
|
|
|
Transaction Exceptions
|
|
======================
|
|
|
|
.. exception:: TransactionManagementError
|
|
|
|
The :exc:`TransactionManagementError` is raised for any and all problems
|
|
related to database transactions. It is available from
|
|
:mod:`django.db.transaction`.
|
|
|
|
Python Exceptions
|
|
=================
|
|
|
|
Django raises built-in Python exceptions when appropriate as well. See the
|
|
Python documentation for further information on the
|
|
built-in :mod:`exceptions`.
|