Fixed #6842 -- Added reference documentation on Django's exceptions. Thanks to timo for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13180 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
f6e7a3aee5
commit
887a4370d4
|
@ -140,6 +140,9 @@ The development process
|
||||||
:ref:`Overview <topics-settings>` |
|
:ref:`Overview <topics-settings>` |
|
||||||
:ref:`Full list of settings <ref-settings>`
|
:ref:`Full list of settings <ref-settings>`
|
||||||
|
|
||||||
|
* **Exceptions:**
|
||||||
|
:ref:`Overview <ref-exceptions>`
|
||||||
|
|
||||||
* **django-admin.py and manage.py:**
|
* **django-admin.py and manage.py:**
|
||||||
:ref:`Overview <ref-django-admin>` |
|
:ref:`Overview <ref-django-admin>` |
|
||||||
:ref:`Adding custom commands <howto-custom-management-commands>`
|
:ref:`Adding custom commands <howto-custom-management-commands>`
|
||||||
|
|
|
@ -0,0 +1,111 @@
|
||||||
|
.. _ref-exceptions:
|
||||||
|
|
||||||
|
=================
|
||||||
|
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
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
The ``DoesNotExist`` exception is raised when an object is not found
|
||||||
|
for the given parameters of a query.
|
||||||
|
|
||||||
|
``ObjectDoesNotExist`` is defined in ``django.core.exceptions``.
|
||||||
|
``DoesNotExist`` is a subclass of the base ``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.QuerySet.get()` for further information
|
||||||
|
on ``ObjectDoesNotExist`` and ``DoesNotExist``.
|
||||||
|
|
||||||
|
MultipleObjectsReturned
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
The ``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 ``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.QuerySet.get()` for further information.
|
||||||
|
|
||||||
|
SuspiciousOperation
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
The ``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
|
||||||
|
----------------
|
||||||
|
|
||||||
|
The ``PermissionDenied`` exception is raised when a user does not have
|
||||||
|
permission to perform the action requested.
|
||||||
|
|
||||||
|
ViewDoesNotExist
|
||||||
|
----------------
|
||||||
|
|
||||||
|
The ``ViewDoesNotExist`` exception is raised by
|
||||||
|
``django.core.urlresolvers`` when a requested view does not exist.
|
||||||
|
|
||||||
|
MiddlewareNotUsed
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
The ``MiddlewareNotUsed`` exception is raised when a middleware is not
|
||||||
|
used in the server configuration.
|
||||||
|
|
||||||
|
ImproperlyConfigured
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
The ``ImproperlyConfigured`` exception is raised when Django is
|
||||||
|
somehow improperly configured -- for example, if a value in ``settings.py``
|
||||||
|
is incorrect or unparseable.
|
||||||
|
|
||||||
|
FieldError
|
||||||
|
----------
|
||||||
|
|
||||||
|
The ``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
|
||||||
|
- If a field cannot be determined from a keyword in the query
|
||||||
|
parameters
|
||||||
|
- If a join is not permitted on the specified field
|
||||||
|
- If a field name is invalid
|
||||||
|
- If a query contains invalid order_by arguments
|
||||||
|
|
||||||
|
Database Exceptions
|
||||||
|
===================
|
||||||
|
|
||||||
|
Django wraps the standard database exceptions ``DatabaseError`` and
|
||||||
|
``IntegrityError`` so that your Django code has a guaranteed common
|
||||||
|
implementation of these classes. These database exceptions are
|
||||||
|
provided in ``django.db``.
|
||||||
|
|
||||||
|
The Django wrappers for database exceptions behave exactly the same as
|
||||||
|
the underlying database exceptions. See `PEP 249 - Python Database API
|
||||||
|
Specification v2.0`_ for further information.
|
||||||
|
|
||||||
|
.. _`PEP 249 - Python Database API Specification v2.0`: http://www.python.org/dev/peps/pep-0249/
|
||||||
|
|
||||||
|
Python Exceptions
|
||||||
|
=================
|
||||||
|
|
||||||
|
Django raises built-in Python exceptions when appropriate as well. See
|
||||||
|
the Python `documentation`_ for further information on the built-in
|
||||||
|
exceptions.
|
||||||
|
|
||||||
|
.. _`documentation`: http://docs.python.org/lib/module-exceptions.html
|
Loading…
Reference in New Issue