Browse files

Fixed #6842 -- Added reference documentation on Django's exceptions. …

…Thanks to timo for the patch.

git-svn-id: bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
freakboy3742 committed May 9, 2010
1 parent f6e7a3a commit 887a4370d41b1bc119ee190a936174ce2ff523c0
Showing with 114 additions and 0 deletions.
  1. +3 −0 docs/index.txt
  2. +111 −0 docs/ref/exceptions.txt
@@ -140,6 +140,9 @@ The development process
:ref:`Overview <topics-settings>` |
:ref:`Full list of settings <ref-settings>`
* **Exceptions:**
:ref:`Overview <ref-exceptions>`
* ** and**
:ref:`Overview <ref-django-admin>` |
:ref:`Adding custom commands <howto-custom-management-commands>`
@@ -0,0 +1,111 @@
.. _ref-exceptions:
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
The ``DoesNotExist`` exception is raised when an object is not found
for the given parameters of a query.
``ObjectDoesNotExist`` is defined in ``django.core.exceptions``.
``DoesNotExist`` is a subclass of the base ``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.QuerySet.get()` for further information
on ``ObjectDoesNotExist`` and ``DoesNotExist``.
The ``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 ``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.QuerySet.get()` for further information.
The ``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.
The ``PermissionDenied`` exception is raised when a user does not have
permission to perform the action requested.
The ``ViewDoesNotExist`` exception is raised by
``django.core.urlresolvers`` when a requested view does not exist.
The ``MiddlewareNotUsed`` exception is raised when a middleware is not
used in the server configuration.
The ``ImproperlyConfigured`` exception is raised when Django is
somehow improperly configured -- for example, if a value in ````
is incorrect or unparseable.
The ``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
- If a field cannot be determined from a keyword in the query
- If a join is not permitted on the specified field
- If a field name is invalid
- If a query contains invalid order_by arguments
Database Exceptions
Django wraps the standard database exceptions ``DatabaseError`` and
``IntegrityError`` so that your Django code has a guaranteed common
implementation of these classes. These database exceptions are
provided in ``django.db``.
The Django wrappers for database exceptions behave exactly the same as
the underlying database exceptions. See `PEP 249 - Python Database API
Specification v2.0`_ for further information.
.. _`PEP 249 - Python Database API Specification v2.0`:
Python Exceptions
Django raises built-in Python exceptions when appropriate as well. See
the Python `documentation`_ for further information on the built-in
.. _`documentation`:

0 comments on commit 887a437

Please sign in to comment.