Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Fixed #14545 -- Added ValidationError to Exceptions Reference docs an…

…d improved Sphinx metadata.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14329 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit e18f8b1d22402dc9e55263360f8875e16af1ab64 1 parent b874549
Gabriel Hurley authored
Showing with 61 additions and 42 deletions.
  1. +61 −42 docs/ref/exceptions.txt
View
103 docs/ref/exceptions.txt
@@ -14,84 +14,103 @@ Django-specific Exceptions
ObjectDoesNotExist and DoesNotExist
-----------------------------------
+.. exception:: DoesNotExist
+.. exception:: ObjectDoesNotExist
-The ``DoesNotExist`` exception is raised when an object is not found
-for the given parameters of a query.
+ The :exc:`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.
+ :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.QuerySet.get()` for further information
-on ``ObjectDoesNotExist`` and ``DoesNotExist``.
+ See :meth:`~django.db.models.QuerySet.get()` for further information
+ on :exc:`ObjectDoesNotExist` and :exc:`DoesNotExist`.
MultipleObjectsReturned
-----------------------
+.. exception:: 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.
+ 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.QuerySet.get()` for further information.
+ See :meth:`~django.db.models.QuerySet.get()` for further information.
SuspiciousOperation
-------------------
+.. exception:: 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.
+ 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 ``PermissionDenied`` exception is raised when a user does not have
-permission to perform the action requested.
+ The :exc:`PermissionDenied` exception is raised when a user does not have
+ permission to perform the action requested.
ViewDoesNotExist
----------------
+.. exception:: ViewDoesNotExist
-The ``ViewDoesNotExist`` exception is raised by
-``django.core.urlresolvers`` when a requested view does not exist.
+ The :exc:`ViewDoesNotExist` exception is raised by
+ :mod:`django.core.urlresolvers` when a requested view does not exist.
MiddlewareNotUsed
-----------------
+.. exception:: MiddlewareNotUsed
-The ``MiddlewareNotUsed`` exception is raised when a middleware is not
-used in the server configuration.
+ The :exc:`MiddlewareNotUsed` exception is raised when a middleware is not
+ used in the server configuration.
ImproperlyConfigured
--------------------
+.. exception:: ImproperlyConfigured
-The ``ImproperlyConfigured`` exception is raised when Django is
-somehow improperly configured -- for example, if a value in ``settings.py``
-is incorrect or unparseable.
+ 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
----------
-
-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
+.. 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>`.
Database Exceptions
===================
-Django wraps the standard database exceptions ``DatabaseError`` and
-``IntegrityError`` so that your Django code has a guaranteed common
+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 ``django.db``.
+provided in :mod:`django.db`.
The Django wrappers for database exceptions behave exactly the same as
the underlying database exceptions. See `PEP 249 - Python Database API
Please sign in to comment.
Something went wrong with that request. Please try again.