=================
Django Exceptions
=================
Django raises some of its own exceptions as well as standard Python exceptions.
Django Core Exceptions
======================
.. module:: django.core.exceptions
:synopsis: Django core exceptions
Django core exception classes are defined in ``django.core.exceptions``.
``AppRegistryNotReady``
-----------------------
.. exception:: AppRegistryNotReady
This exception is raised when attempting to use models before the :ref:`app
loading process <app-loading-process>`, which initializes the ORM, is
complete.
``ObjectDoesNotExist``
----------------------
.. exception:: ObjectDoesNotExist
The base class for :exc:`~django.db.models.Model.DoesNotExist` exceptions;
a ``try/except`` for ``ObjectDoesNotExist`` will catch
:exc:`~django.db.models.Model.DoesNotExist` exceptions for all models.
See :meth:`~django.db.models.query.QuerySet.get()` for further information
on :exc:`ObjectDoesNotExist` and :exc:`~django.db.models.Model.DoesNotExist`.
``EmptyResultSet``
------------------
.. exception:: EmptyResultSet
``EmptyResultSet`` may be raised during query generation if a query won't
return any results. Most Django projects won't encounter this exception,
but it might be useful for implementing custom lookups and expressions.
.. versionchanged:: 1.11
In older versions, it's only importable from ``django.db.models.sql``.
``FieldDoesNotExist``
---------------------
.. exception:: FieldDoesNotExist
The ``FieldDoesNotExist`` exception is raised by a model's
``_meta.get_field()`` method when the requested field does not exist on the
model or on the model's parents.
``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. Subclasses of
``SuspiciousOperation`` include:
* ``DisallowedHost``
* ``DisallowedModelAdminLookup``
* ``DisallowedModelAdminToField``
* ``DisallowedRedirect``
* ``InvalidSessionKey``
* ``RequestDataTooBig``
* ``SuspiciousFileOperation``
* ``SuspiciousMultipartForm``
* ``SuspiciousSession``
* ``TooManyFieldsSent``
If a ``SuspiciousOperation`` exception reaches the WSGI handler level it is
logged at the ``Error`` level and results in
a :class:`~django.http.HttpResponseBadRequest`. See the :doc:`logging
documentation </topics/logging/>` for more information.
``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.urls` 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>`.
``NON_FIELD_ERRORS``
~~~~~~~~~~~~~~~~~~~~
.. data:: NON_FIELD_ERRORS
``ValidationError``\s that don't belong to a particular field in a form
or model are classified as ``NON_FIELD_ERRORS``. This constant is used
as a key in dictionaries that otherwise map fields to their respective
list of errors.
.. currentmodule:: django.urls
URL Resolver exceptions
=======================
URL Resolver exceptions are defined in ``django.urls``.
.. deprecated:: 1.10
In older versions, these exceptions are located in
``django.core.urlresolvers``. Importing from the old location will continue
to work until Django 2.0.
``Resolver404``
---------------
.. exception:: Resolver404
The :exc:`Resolver404` exception is raised by
:func:`~django.urls.resolve()` if the path passed to ``resolve()`` doesn't
map to a view. It's a subclass of :class:`django.http.Http404`.
``NoReverseMatch``
------------------
.. exception:: NoReverseMatch
The :exc:`NoReverseMatch` exception is raised by :mod:`django.urls` when a
matching URL in your URLconf cannot be identified based on the parameters
supplied.
.. currentmodule:: django.db
Database Exceptions
===================
Database exceptions may be imported from ``django.db``.
Django wraps the standard database exceptions so that your Django code has a
guaranteed common implementation of these classes.
.. 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.
As per :pep:`3134`, a ``__cause__`` attribute is set with the original
(underlying) database exception, allowing access to any additional
information provided. (Note that this attribute is available under
both Python 2 and Python 3, although :pep:`3134` normally only applies
to Python 3. To avoid unexpected differences with Python 3, Django will also
ensure that the exception made available via ``__cause__`` has a usable
``__traceback__`` attribute.)
.. versionchanged:: 1.10
The ``__traceback__`` attribute described above was added.
.. exception:: models.ProtectedError
Raised to prevent deletion of referenced objects when using
:attr:`django.db.models.PROTECT`. :exc:`models.ProtectedError` is a subclass
of :exc:`IntegrityError`.
.. currentmodule:: django.http
Http Exceptions
===============
Http exceptions may be imported from ``django.http``.
``UnreadablePostError``
-----------------------
.. exception:: UnreadablePostError
:exc:`UnreadablePostError` is raised when a user cancels an upload.
Transaction Exceptions
======================
.. currentmodule:: django.db.transaction
Transaction exceptions are defined in ``django.db.transaction``.
``TransactionManagementError``
------------------------------
.. exception:: TransactionManagementError
:exc:`TransactionManagementError` is raised for any and all problems
related to database transactions.
.. currentmodule:: django.test
Testing Framework Exceptions
============================
Exceptions provided by the ``django.test`` package.
``RedirectCycleError``
----------------------
.. exception:: client.RedirectCycleError
:exc:`~client.RedirectCycleError` is raised when the test client detects a
loop or an overly long chain of redirects.
Python Exceptions
=================
Django raises built-in Python exceptions when appropriate as well. See the
Python documentation for further information on the :ref:`bltin-exceptions`.
