123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268 |
- =================
- 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``.
- ``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 </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`.
|