================= 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 `, 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`. ``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 ` 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:`Model Field Validation ` and the :doc:`Validator Reference `. ``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`.