2010-05-09 07:45:05 +00:00
|
|
|
=================
|
|
|
|
Django Exceptions
|
|
|
|
=================
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
Django raises some of its own exceptions as well as standard Python exceptions.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2013-08-01 21:27:11 +00:00
|
|
|
Django Core Exceptions
|
|
|
|
======================
|
2010-05-09 07:45:05 +00:00
|
|
|
|
|
|
|
.. module:: django.core.exceptions
|
2013-08-01 21:27:11 +00:00
|
|
|
:synopsis: Django core exceptions
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
Django core exception classes are defined in ``django.core.exceptions``.
|
|
|
|
|
2016-10-06 14:20:22 +00:00
|
|
|
``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.
|
|
|
|
|
2015-05-08 01:30:04 +00:00
|
|
|
``ObjectDoesNotExist``
|
|
|
|
----------------------
|
2013-08-01 21:27:11 +00:00
|
|
|
|
|
|
|
.. exception:: ObjectDoesNotExist
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-05-08 01:30:04 +00:00
|
|
|
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.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2011-03-22 20:12:17 +00:00
|
|
|
See :meth:`~django.db.models.query.QuerySet.get()` for further information
|
2015-05-08 01:30:04 +00:00
|
|
|
on :exc:`ObjectDoesNotExist` and :exc:`~django.db.models.Model.DoesNotExist`.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2016-05-25 19:00:20 +00:00
|
|
|
``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.
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``FieldDoesNotExist``
|
|
|
|
---------------------
|
|
|
|
|
2015-01-02 15:14:23 +00:00
|
|
|
.. 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.
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``MultipleObjectsReturned``
|
|
|
|
---------------------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. exception:: MultipleObjectsReturned
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
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.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2011-03-22 20:12:17 +00:00
|
|
|
See :meth:`~django.db.models.query.QuerySet.get()` for further information.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``SuspiciousOperation``
|
|
|
|
-----------------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. exception:: SuspiciousOperation
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2013-05-15 23:14:28 +00:00
|
|
|
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
|
2015-02-22 15:24:03 +00:00
|
|
|
``SuspiciousOperation`` include:
|
|
|
|
|
|
|
|
* ``DisallowedHost``
|
|
|
|
* ``DisallowedModelAdminLookup``
|
|
|
|
* ``DisallowedModelAdminToField``
|
|
|
|
* ``DisallowedRedirect``
|
|
|
|
* ``InvalidSessionKey``
|
2015-01-07 18:41:29 +00:00
|
|
|
* ``RequestDataTooBig``
|
2015-02-22 15:24:03 +00:00
|
|
|
* ``SuspiciousFileOperation``
|
|
|
|
* ``SuspiciousMultipartForm``
|
|
|
|
* ``SuspiciousSession``
|
2015-01-07 18:41:29 +00:00
|
|
|
* ``TooManyFieldsSent``
|
2013-05-15 23:14:28 +00:00
|
|
|
|
|
|
|
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.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``PermissionDenied``
|
|
|
|
--------------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. exception:: PermissionDenied
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
The :exc:`PermissionDenied` exception is raised when a user does not have
|
|
|
|
permission to perform the action requested.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``ViewDoesNotExist``
|
|
|
|
--------------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. exception:: ViewDoesNotExist
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
The :exc:`ViewDoesNotExist` exception is raised by
|
2015-12-30 15:51:16 +00:00
|
|
|
:mod:`django.urls` when a requested view does not exist.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``MiddlewareNotUsed``
|
|
|
|
---------------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. exception:: MiddlewareNotUsed
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
The :exc:`MiddlewareNotUsed` exception is raised when a middleware is not
|
|
|
|
used in the server configuration.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``ImproperlyConfigured``
|
|
|
|
------------------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. exception:: ImproperlyConfigured
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
The :exc:`ImproperlyConfigured` exception is raised when Django is
|
|
|
|
somehow improperly configured -- for example, if a value in ``settings.py``
|
|
|
|
is incorrect or unparseable.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``FieldError``
|
|
|
|
--------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. exception:: FieldError
|
|
|
|
|
|
|
|
The :exc:`FieldError` exception is raised when there is a problem with a
|
|
|
|
model field. This can happen for several reasons:
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
- 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
|
2010-10-23 21:15:35 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``ValidationError``
|
|
|
|
-------------------
|
|
|
|
|
2010-10-23 21:15:35 +00:00
|
|
|
.. 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>`.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``NON_FIELD_ERRORS``
|
|
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2014-02-03 18:31:27 +00:00
|
|
|
.. 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
|
2014-02-22 17:30:28 +00:00
|
|
|
as a key in dictionaries that otherwise map fields to their respective
|
2014-02-03 18:31:27 +00:00
|
|
|
list of errors.
|
|
|
|
|
2019-04-12 13:15:18 +00:00
|
|
|
``RequestAborted``
|
|
|
|
------------------
|
|
|
|
|
|
|
|
.. exception:: RequestAborted
|
|
|
|
|
|
|
|
.. versionadded:: 3.0
|
|
|
|
|
|
|
|
The :exc:`RequestAborted` exception is raised when a HTTP body being read
|
|
|
|
in by the handler is cut off midstream and the client connection closes,
|
|
|
|
or when the client does not send data and hits a timeout where the server
|
|
|
|
closes the connection.
|
|
|
|
|
|
|
|
It is internal to the HTTP handler modules and you are unlikely to see
|
|
|
|
it elsewhere. If you are modifying HTTP handling code, you should raise
|
|
|
|
this when you encounter an aborted request to make sure the socket is
|
|
|
|
closed cleanly.
|
|
|
|
|
|
|
|
``SynchronousOnlyOperation``
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
.. exception:: SynchronousOnlyOperation
|
|
|
|
|
|
|
|
.. versionadded:: 3.0
|
|
|
|
|
|
|
|
The :exc:`SynchronousOnlyOperation` exception is raised when code that
|
|
|
|
is only allowed in synchronous Python code is called from an asynchronous
|
|
|
|
context (a thread with a running asynchronous event loop). These parts of
|
|
|
|
Django are generally heavily reliant on thread-safety to function and don't
|
|
|
|
work correctly under coroutines sharing the same thread.
|
|
|
|
|
|
|
|
If you are trying to call code that is synchronous-only from an
|
|
|
|
asynchronous thread, then create a synchronous thread and call it in that.
|
|
|
|
You can accomplish this is with ``asgiref.sync.sync_to_async``.
|
|
|
|
|
2015-12-30 15:51:16 +00:00
|
|
|
.. currentmodule:: django.urls
|
2011-03-03 19:31:10 +00:00
|
|
|
|
2013-08-01 21:27:11 +00:00
|
|
|
URL Resolver exceptions
|
|
|
|
=======================
|
|
|
|
|
2015-12-30 15:51:16 +00:00
|
|
|
URL Resolver exceptions are defined in ``django.urls``.
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``Resolver404``
|
|
|
|
---------------
|
2013-08-01 21:27:11 +00:00
|
|
|
|
2013-09-05 12:43:10 +00:00
|
|
|
.. exception:: Resolver404
|
|
|
|
|
|
|
|
The :exc:`Resolver404` exception is raised by
|
2015-12-30 15:51:16 +00:00
|
|
|
: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`.
|
2015-02-22 15:24:03 +00:00
|
|
|
|
|
|
|
``NoReverseMatch``
|
|
|
|
------------------
|
2013-09-05 12:43:10 +00:00
|
|
|
|
2011-03-03 19:31:10 +00:00
|
|
|
.. exception:: NoReverseMatch
|
|
|
|
|
2015-12-30 15:51:16 +00:00
|
|
|
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.
|
2011-03-03 19:31:10 +00:00
|
|
|
|
|
|
|
.. currentmodule:: django.db
|
|
|
|
|
2010-05-09 07:45:05 +00:00
|
|
|
Database Exceptions
|
|
|
|
===================
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
Database exceptions may be imported from ``django.db``.
|
2013-08-01 21:27:11 +00:00
|
|
|
|
Refactored database exceptions wrapping.
Squashed commit of the following:
commit 2181d833ed1a2e422494738dcef311164c4e097e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Wed Feb 27 14:28:39 2013 +0100
Fixed #15901 -- Wrapped all PEP-249 exceptions.
commit 5476a5d93c19aa2f928c497d39ce6e33f52694e2
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:26:52 2013 +0100
Added PEP 3134 exception chaining.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 9365fad0a650328002fb424457d675a273c95802
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:13:49 2013 +0100
Improved API for wrapping database errors.
Thanks Alex Gaynor for the proposal.
commit 1b463b765f2826f73a8d9266795cd5da4f8d5e9e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 15:00:39 2013 +0100
Removed redundant exception wrapping.
This is now taken care of by the cursor wrapper.
commit 524bc7345a724bf526bdd2dd1bcf5ede67d6bb5c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:55:10 2013 +0100
Wrapped database exceptions in the base backend.
This covers the most common PEP-249 APIs:
- Connection APIs: close(), commit(), rollback(), cursor()
- Cursor APIs: callproc(), close(), execute(), executemany(),
fetchone(), fetchmany(), fetchall(), nextset().
Fixed #19920.
commit a66746bb5f0839f35543222787fce3b6a0d0a3ea
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:53:34 2013 +0100
Added a wrap_database_exception context manager and decorator.
It re-throws backend-specific exceptions using Django's common wrappers.
2013-02-26 13:53:34 +00:00
|
|
|
Django wraps the standard database exceptions so that your Django code has a
|
2013-08-01 21:27:11 +00:00
|
|
|
guaranteed common implementation of these classes.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
Refactored database exceptions wrapping.
Squashed commit of the following:
commit 2181d833ed1a2e422494738dcef311164c4e097e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Wed Feb 27 14:28:39 2013 +0100
Fixed #15901 -- Wrapped all PEP-249 exceptions.
commit 5476a5d93c19aa2f928c497d39ce6e33f52694e2
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:26:52 2013 +0100
Added PEP 3134 exception chaining.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 9365fad0a650328002fb424457d675a273c95802
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:13:49 2013 +0100
Improved API for wrapping database errors.
Thanks Alex Gaynor for the proposal.
commit 1b463b765f2826f73a8d9266795cd5da4f8d5e9e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 15:00:39 2013 +0100
Removed redundant exception wrapping.
This is now taken care of by the cursor wrapper.
commit 524bc7345a724bf526bdd2dd1bcf5ede67d6bb5c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:55:10 2013 +0100
Wrapped database exceptions in the base backend.
This covers the most common PEP-249 APIs:
- Connection APIs: close(), commit(), rollback(), cursor()
- Cursor APIs: callproc(), close(), execute(), executemany(),
fetchone(), fetchmany(), fetchall(), nextset().
Fixed #19920.
commit a66746bb5f0839f35543222787fce3b6a0d0a3ea
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:53:34 2013 +0100
Added a wrap_database_exception context manager and decorator.
It re-throws backend-specific exceptions using Django's common wrappers.
2013-02-26 13:53:34 +00:00
|
|
|
.. exception:: Error
|
|
|
|
.. exception:: InterfaceError
|
2011-03-03 19:31:10 +00:00
|
|
|
.. exception:: DatabaseError
|
Refactored database exceptions wrapping.
Squashed commit of the following:
commit 2181d833ed1a2e422494738dcef311164c4e097e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Wed Feb 27 14:28:39 2013 +0100
Fixed #15901 -- Wrapped all PEP-249 exceptions.
commit 5476a5d93c19aa2f928c497d39ce6e33f52694e2
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:26:52 2013 +0100
Added PEP 3134 exception chaining.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 9365fad0a650328002fb424457d675a273c95802
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:13:49 2013 +0100
Improved API for wrapping database errors.
Thanks Alex Gaynor for the proposal.
commit 1b463b765f2826f73a8d9266795cd5da4f8d5e9e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 15:00:39 2013 +0100
Removed redundant exception wrapping.
This is now taken care of by the cursor wrapper.
commit 524bc7345a724bf526bdd2dd1bcf5ede67d6bb5c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:55:10 2013 +0100
Wrapped database exceptions in the base backend.
This covers the most common PEP-249 APIs:
- Connection APIs: close(), commit(), rollback(), cursor()
- Cursor APIs: callproc(), close(), execute(), executemany(),
fetchone(), fetchmany(), fetchall(), nextset().
Fixed #19920.
commit a66746bb5f0839f35543222787fce3b6a0d0a3ea
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:53:34 2013 +0100
Added a wrap_database_exception context manager and decorator.
It re-throws backend-specific exceptions using Django's common wrappers.
2013-02-26 13:53:34 +00:00
|
|
|
.. exception:: DataError
|
|
|
|
.. exception:: OperationalError
|
2011-03-03 19:31:10 +00:00
|
|
|
.. exception:: IntegrityError
|
Refactored database exceptions wrapping.
Squashed commit of the following:
commit 2181d833ed1a2e422494738dcef311164c4e097e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Wed Feb 27 14:28:39 2013 +0100
Fixed #15901 -- Wrapped all PEP-249 exceptions.
commit 5476a5d93c19aa2f928c497d39ce6e33f52694e2
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:26:52 2013 +0100
Added PEP 3134 exception chaining.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 9365fad0a650328002fb424457d675a273c95802
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 17:13:49 2013 +0100
Improved API for wrapping database errors.
Thanks Alex Gaynor for the proposal.
commit 1b463b765f2826f73a8d9266795cd5da4f8d5e9e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 15:00:39 2013 +0100
Removed redundant exception wrapping.
This is now taken care of by the cursor wrapper.
commit 524bc7345a724bf526bdd2dd1bcf5ede67d6bb5c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:55:10 2013 +0100
Wrapped database exceptions in the base backend.
This covers the most common PEP-249 APIs:
- Connection APIs: close(), commit(), rollback(), cursor()
- Cursor APIs: callproc(), close(), execute(), executemany(),
fetchone(), fetchmany(), fetchall(), nextset().
Fixed #19920.
commit a66746bb5f0839f35543222787fce3b6a0d0a3ea
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Feb 26 14:53:34 2013 +0100
Added a wrap_database_exception context manager and decorator.
It re-throws backend-specific exceptions using Django's common wrappers.
2013-02-26 13:53:34 +00:00
|
|
|
.. exception:: InternalError
|
|
|
|
.. exception:: ProgrammingError
|
|
|
|
.. exception:: NotSupportedError
|
2011-03-03 19:31:10 +00:00
|
|
|
|
2010-05-09 07:45:05 +00:00
|
|
|
The Django wrappers for database exceptions behave exactly the same as
|
2011-09-04 21:17:30 +00:00
|
|
|
the underlying database exceptions. See :pep:`249`, the Python Database API
|
|
|
|
Specification v2.0, for further information.
|
2010-05-09 07:45:05 +00:00
|
|
|
|
2013-06-04 11:31:06 +00:00
|
|
|
As per :pep:`3134`, a ``__cause__`` attribute is set with the original
|
|
|
|
(underlying) database exception, allowing access to any additional
|
2017-01-18 16:51:29 +00:00
|
|
|
information provided.
|
2015-11-25 11:54:52 +00:00
|
|
|
|
2013-01-01 13:12:42 +00:00
|
|
|
.. exception:: models.ProtectedError
|
|
|
|
|
|
|
|
Raised to prevent deletion of referenced objects when using
|
2013-08-01 21:27:11 +00:00
|
|
|
:attr:`django.db.models.PROTECT`. :exc:`models.ProtectedError` is a subclass
|
|
|
|
of :exc:`IntegrityError`.
|
2013-01-01 13:12:42 +00:00
|
|
|
|
|
|
|
.. currentmodule:: django.http
|
|
|
|
|
|
|
|
Http Exceptions
|
|
|
|
===============
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
Http exceptions may be imported from ``django.http``.
|
2013-08-01 21:27:11 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
``UnreadablePostError``
|
|
|
|
-----------------------
|
2013-01-01 13:12:42 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
.. exception:: UnreadablePostError
|
2013-01-01 13:12:42 +00:00
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
:exc:`UnreadablePostError` is raised when a user cancels an upload.
|
2011-03-22 20:12:17 +00:00
|
|
|
|
|
|
|
Transaction Exceptions
|
|
|
|
======================
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
.. currentmodule:: django.db.transaction
|
|
|
|
|
|
|
|
Transaction exceptions are defined in ``django.db.transaction``.
|
|
|
|
|
|
|
|
``TransactionManagementError``
|
|
|
|
------------------------------
|
2013-08-01 21:27:11 +00:00
|
|
|
|
2011-03-22 20:12:17 +00:00
|
|
|
.. exception:: TransactionManagementError
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
:exc:`TransactionManagementError` is raised for any and all problems
|
2013-08-01 21:27:11 +00:00
|
|
|
related to database transactions.
|
2011-03-22 20:12:17 +00:00
|
|
|
|
2014-10-17 13:46:42 +00:00
|
|
|
.. currentmodule:: django.test
|
|
|
|
|
|
|
|
Testing Framework Exceptions
|
|
|
|
============================
|
|
|
|
|
2015-02-22 15:24:03 +00:00
|
|
|
Exceptions provided by the ``django.test`` package.
|
|
|
|
|
|
|
|
``RedirectCycleError``
|
|
|
|
----------------------
|
2014-10-17 13:46:42 +00:00
|
|
|
|
|
|
|
.. exception:: client.RedirectCycleError
|
|
|
|
|
|
|
|
:exc:`~client.RedirectCycleError` is raised when the test client detects a
|
|
|
|
loop or an overly long chain of redirects.
|
|
|
|
|
2010-05-09 07:45:05 +00:00
|
|
|
Python Exceptions
|
|
|
|
=================
|
|
|
|
|
2011-09-04 21:17:30 +00:00
|
|
|
Django raises built-in Python exceptions when appropriate as well. See the
|
2014-04-26 14:00:15 +00:00
|
|
|
Python documentation for further information on the :ref:`bltin-exceptions`.
|