← Back to branch summary

~ubuntu-branches/ubuntu/natty/python-django/natty-security

« back to all changes in this revision

Viewing changes to docs/ref/exceptions.txt

  • Committer: Bazaar Package Importer
  • Author(s): Chris Lamb
  • Date: 2010-05-21 07:52:55 UTC
  • mfrom: (1.1.10 upstream) (4.4.7 sid)
  • Revision ID: james.westby@ubuntu.com-20100521075255-i1zpeyc0k8512pd7
Tags: 1.2-1
New upstream stable release.

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/ref/exceptions.txt
 
1
.. _ref-exceptions:
 
2
 
 
3
=================
 
4
Django Exceptions
 
5
=================
 
6
 
 
7
 
 
8
Django raises some Django specific exceptions as well as many standard
 
9
Python exceptions.
 
10
 
 
11
Django-specific Exceptions
 
12
==========================
 
13
 
 
14
.. module:: django.core.exceptions
 
15
    :synopsis: Django specific exceptions
 
16
 
 
17
ObjectDoesNotExist and DoesNotExist
 
18
-----------------------------------
 
19
 
 
20
The ``DoesNotExist`` exception is raised when an object is not found
 
21
for the given parameters of a query.
 
22
 
 
23
``ObjectDoesNotExist`` is defined in ``django.core.exceptions``.
 
24
``DoesNotExist`` is a subclass of the base ``ObjectDoesNotExist``
 
25
exception that is provided on every model class as a way of
 
26
identifying the specific type of object that could not be found.
 
27
 
 
28
See :meth:`~django.db.models.QuerySet.get()` for further information
 
29
on ``ObjectDoesNotExist`` and ``DoesNotExist``.
 
30
 
 
31
MultipleObjectsReturned
 
32
-----------------------
 
33
 
 
34
The ``MultipleObjectsReturned`` exception is raised by a query if only
 
35
one object is expected, but multiple objects are returned. A base version
 
36
of this exception is provided in ``django.core.exceptions``; each model
 
37
class contains a subclassed version that can be used to identify the
 
38
specific object type that has returned multiple objects.
 
39
 
 
40
See :meth:`~django.db.models.QuerySet.get()` for further information.
 
41
 
 
42
SuspiciousOperation
 
43
-------------------
 
44
 
 
45
The ``SuspiciousOperation`` exception is raised when a user has performed
 
46
an operation that should be considered suspicious from a security perspective,
 
47
such as tampering with a session cookie.
 
48
 
 
49
PermissionDenied
 
50
----------------
 
51
 
 
52
The ``PermissionDenied`` exception is raised when a user does not have
 
53
permission to perform the action requested.
 
54
 
 
55
ViewDoesNotExist
 
56
----------------
 
57
 
 
58
The ``ViewDoesNotExist`` exception is raised by
 
59
``django.core.urlresolvers`` when a requested view does not exist.
 
60
 
 
61
MiddlewareNotUsed
 
62
-----------------
 
63
 
 
64
The ``MiddlewareNotUsed`` exception is raised when a middleware is not
 
65
used in the server configuration.
 
66
 
 
67
ImproperlyConfigured
 
68
--------------------
 
69
 
 
70
The ``ImproperlyConfigured`` exception is raised when Django is
 
71
somehow improperly configured -- for example, if a value in ``settings.py``
 
72
is incorrect or unparseable.
 
73
 
 
74
FieldError
 
75
----------
 
76
 
 
77
The ``FieldError`` exception is raised when there is a problem with a
 
78
model field. This can happen for several reasons:
 
79
 
 
80
    - A field in a model clashes with a field of the same name from an
 
81
      abstract base class
 
82
    - An infinite loop is caused by ordering
 
83
    - A keyword cannot be parsed from the filter parameters
 
84
    - If a field cannot be determined from a keyword in the query
 
85
      parameters
 
86
    - If a join is not permitted on the specified field
 
87
    - If a field name is invalid
 
88
    - If a query contains invalid order_by arguments
 
89
 
 
90
Database Exceptions
 
91
===================
 
92
 
 
93
Django wraps the standard database exceptions ``DatabaseError`` and
 
94
``IntegrityError`` so that your Django code has a guaranteed common
 
95
implementation of these classes. These database exceptions are
 
96
provided in ``django.db``.
 
97
 
 
98
The Django wrappers for database exceptions behave exactly the same as
 
99
the underlying database exceptions. See `PEP 249 - Python Database API
 
100
Specification v2.0`_ for further information.
 
101
 
 
102
.. _`PEP 249 - Python Database API Specification v2.0`: http://www.python.org/dev/peps/pep-0249/
 
103
 
 
104
Python Exceptions
 
105
=================
 
106
 
 
107
Django raises built-in Python exceptions when appropriate as well. See
 
108
the Python `documentation`_ for further information on the built-in
 
109
exceptions.
 
110
 
 
111
.. _`documentation`: http://docs.python.org/lib/module-exceptions.html