| ================= |
| 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 |
| ----------------------------------- |
| .. exception:: DoesNotExist |
| .. exception:: ObjectDoesNotExist |
| |
| The :exc:`DoesNotExist` exception is raised when an object is not found |
| for the given parameters of a query. |
| |
| :exc:`ObjectDoesNotExist` is defined in :mod:`django.core.exceptions`. |
| :exc:`DoesNotExist` is a subclass of the base :exc:`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.query.QuerySet.get()` for further information |
| on :exc:`ObjectDoesNotExist` and :exc:`DoesNotExist`. |
| |
| 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. |
| |
| 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.core.urlresolvers` 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>`. |
| |
| .. currentmodule:: django.core.urlresolvers |
| |
| NoReverseMatch |
| -------------- |
| .. exception:: NoReverseMatch |
| |
| The :exc:`NoReverseMatch` exception is raised by |
| :mod:`django.core.urlresolvers` when a matching URL in your URLconf |
| cannot be identified based on the parameters supplied. |
| |
| .. currentmodule:: django.db |
| |
| Database Exceptions |
| =================== |
| |
| Django wraps the standard database exceptions :exc:`DatabaseError` and |
| :exc:`IntegrityError` so that your Django code has a guaranteed common |
| implementation of these classes. These database exceptions are |
| provided in :mod:`django.db`. |
| |
| .. exception:: DatabaseError |
| .. exception:: IntegrityError |
| |
| 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. |
| |
| .. exception:: models.ProtectedError |
| |
| Raised to prevent deletion of referenced objects when using |
| :attr:`django.db.models.PROTECT`. Subclass of :exc:`IntegrityError`. |
| |
| .. currentmodule:: django.http |
| |
| Http Exceptions |
| =============== |
| |
| .. exception:: UnreadablePostError |
| |
| The :exc:`UnreadablePostError` is raised when a user cancels an upload. |
| It is available from :mod:`django.http`. |
| |
| .. currentmodule:: django.db.transaction |
| |
| Transaction Exceptions |
| ====================== |
| |
| .. exception:: TransactionManagementError |
| |
| The :exc:`TransactionManagementError` is raised for any and all problems |
| related to database transactions. It is available from |
| :mod:`django.db.transaction`. |
| |
| Python Exceptions |
| ================= |
| |
| Django raises built-in Python exceptions when appropriate as well. See the |
| Python documentation for further information on the |
| built-in :mod:`exceptions`. |