Django raises some Django specific exceptions as well as many standard Python 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.
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.
- 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.
See get() for further information.
- exception 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
- 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
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.
- 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¶