[1.1.X] Fixed #6842 -- Added reference documentation on Django's exceptions....

      :ref:`Overview <topics-settings>` |

      :ref:`Full list of settings <ref-settings>`

    * **Exceptions:**

      :ref:`Overview <ref-exceptions>`

    * **django-admin.py and manage.py:**

      :ref:`Overview <ref-django-admin>` |

      :ref:`Adding custom commands <howto-custom-management-commands>`

.. _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``.

MultipleObjectsReturned

-----------------------

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.

SuspiciousOperation

-------------------

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.

PermissionDenied

----------------

The ``PermissionDenied`` exception is raised when a user does not have

permission to perform the action requested.

ViewDoesNotExist

----------------

The ``ViewDoesNotExist`` exception is raised by

``django.core.urlresolvers`` when a requested view does not exist.

MiddlewareNotUsed

-----------------

The ``MiddlewareNotUsed`` exception is raised when a middleware is not

used in the server configuration.

ImproperlyConfigured

--------------------

The ``ImproperlyConfigured`` exception is raised when Django is

somehow improperly configured -- for example, if a value in ``settings.py``

is incorrect or unparseable.

FieldError

----------

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

      parameters

    - 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`: http://www.python.org/dev/peps/pep-0249/

Python Exceptions

=================

Django raises built-in Python exceptions when appropriate as well. See

the Python `documentation`_ for further information on the built-in

exceptions.

.. _`documentation`: http://docs.python.org/lib/module-exceptions.html