---
title: "Django Exceções"
version: 1.11
locale: pt-br
source: https://docs.djangoproject.com/pt-br/1.11/ref/exceptions/
canonical: https://djangodocs.dev/pt-br/1.11/ref/exceptions/
---
# Django Exceções

Django raises some of its own exceptions as well as standard Python exceptions.

## Django Core Exceptions

Django core exception classes are defined in `django.core.exceptions`.

### `AppRegistryNotReady`

#### `exception AppRegistryNotReady`

This exception is raised when attempting to use models before the [app
loading process](/pt-br/1.11/ref/applications/#app-loading-process), which initializes the ORM, is
complete.

### `ObjectDoesNotExist`

#### `exception ObjectDoesNotExist`

The base class for [`DoesNotExist`](/pt-br/1.11/ref/models/instances/#django.db.models.Model.DoesNotExist) exceptions;
a `try/except` for `ObjectDoesNotExist` will catch
[`DoesNotExist`](/pt-br/1.11/ref/models/instances/#django.db.models.Model.DoesNotExist) exceptions for all models.

See [`get()`](/pt-br/1.11/ref/models/querysets/#django.db.models.query.QuerySet.get) for further information
on [`ObjectDoesNotExist`](#django.core.exceptions.ObjectDoesNotExist) and [`DoesNotExist`](/pt-br/1.11/ref/models/instances/#django.db.models.Model.DoesNotExist).

### `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.

> **Changed in Django 1.11**
>
> In older versions, it’s only importable from `django.db.models.sql`.

### `FieldDoesNotExist`

#### `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.

### `MultipleObjectsReturned`

#### `exception MultipleObjectsReturned`

The [`MultipleObjectsReturned`](#django.core.exceptions.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`](#module-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()`](/pt-br/1.11/ref/models/querysets/#django.db.models.query.QuerySet.get) for further information.

### `SuspiciousOperation`

#### `exception SuspiciousOperation`

The [`SuspiciousOperation`](#django.core.exceptions.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
`SuspiciousOperation` include:

- `DisallowedHost`
- `DisallowedModelAdminLookup`
- `DisallowedModelAdminToField`
- `DisallowedRedirect`
- `InvalidSessionKey`
- `RequestDataTooBig`
- `SuspiciousFileOperation`
- `SuspiciousMultipartForm`
- `SuspiciousSession`
- `TooManyFieldsSent`

If a `SuspiciousOperation` exception reaches the WSGI handler level it is
logged at the `Error` level and results in
a [`HttpResponseBadRequest`](/pt-br/1.11/ref/request-response/#django.http.HttpResponseBadRequest). See the [logging
documentation](/pt-br/1.11/topics/logging/) for more information.

### `PermissionDenied`

#### `exception PermissionDenied`

The [`PermissionDenied`](#django.core.exceptions.PermissionDenied) exception is raised when a user does not have
permission to perform the action requested.

### `ViewDoesNotExist`

#### `exception ViewDoesNotExist`

The [`ViewDoesNotExist`](#django.core.exceptions.ViewDoesNotExist) exception is raised by
[`django.urls`](/pt-br/1.11/ref/urlresolvers/#module-django.urls) when a requested view does not exist.

### `MiddlewareNotUsed`

#### `exception MiddlewareNotUsed`

The [`MiddlewareNotUsed`](#django.core.exceptions.MiddlewareNotUsed) exception is raised when a middleware is not
used in the server configuration.

### `ImproperlyConfigured`

#### `exception ImproperlyConfigured`

The [`ImproperlyConfigured`](#django.core.exceptions.ImproperlyConfigured) exception is raised when Django is
somehow improperly configured – for example, if a value in `settings.py`
is incorrect or unparseable.

### `FieldError`

#### `exception FieldError`

The [`FieldError`](#django.core.exceptions.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
- O nome do campo é inválido
- A query contains invalid order\_by arguments

### `ValidationError`

#### `exception ValidationError`

The [`ValidationError`](#django.core.exceptions.ValidationError) exception is raised when data fails form or
model field validation. For more information about validation, see
[Form and Field Validation](/pt-br/1.11/ref/forms/validation/),
[Model Field Validation](/pt-br/1.11/ref/models/instances/#validating-objects) and the
[Validator Reference](/pt-br/1.11/ref/validators/).

#### `NON_FIELD_ERRORS`

#### `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
as a key in dictionaries that otherwise map fields to their respective
list of errors.

## URL Resolver exceptions

URL Resolver exceptions are defined in `django.urls`.

> **Deprecated since Django 1.10**
>
> Descontinuado desde a versão 1.10: In older versions, these exceptions are located in
> `django.core.urlresolvers`. Importing from the old location will continue
> to work until Django 2.0.

### `Resolver404`

#### `exception Resolver404`

The [`Resolver404`](#django.urls.Resolver404) exception is raised by
[`resolve()`](/pt-br/1.11/ref/urlresolvers/#django.urls.resolve) if the path passed to `resolve()` doesn’t
map to a view. It’s a subclass of [`django.http.Http404`](/pt-br/1.11/topics/http/views/#django.http.Http404).

### `NoReverseMatch`

#### `exception NoReverseMatch`

The [`NoReverseMatch`](#django.urls.NoReverseMatch) exception is raised by [`django.urls`](/pt-br/1.11/ref/urlresolvers/#module-django.urls) when a
matching URL in your URLconf cannot be identified based on the parameters
supplied.

## Exceções de Banco de dados

Database exceptions may be imported from `django.db`.

Django wraps the standard database exceptions so that your Django code has a
guaranteed common implementation of these classes.

#### `exception Error`

#### `exception InterfaceError`

#### `exception DatabaseError`

#### `exception DataError`

#### `exception OperationalError`

#### `exception IntegrityError`

#### `exception InternalError`

#### `exception ProgrammingError`

#### `exception NotSupportedError`

The Django wrappers for database exceptions behave exactly the same as
the underlying database exceptions. See [**PEP 249**](https://peps.python.org/pep-0249/), the Python Database API
Specification v2.0, for further information.

As per [**PEP 3134**](https://peps.python.org/pep-3134/), a `__cause__` attribute is set with the original
(underlying) database exception, allowing access to any additional
information provided. (Note that this attribute is available under
both Python 2 and Python 3, although [**PEP 3134**](https://peps.python.org/pep-3134/) normally only applies
to Python 3. To avoid unexpected differences with Python 3, Django will also
ensure that the exception made available via `__cause__` has a usable
`__traceback__` attribute.)

> **Changed in Django 1.10**
>
> The `__traceback__` attribute described above was added.

#### `exception models.ProtectedError`

Raised to prevent deletion of referenced objects when using
[`django.db.models.PROTECT`](/pt-br/1.11/ref/models/fields/#django.db.models.PROTECT). [`models.ProtectedError`](#django.db.models.ProtectedError) is a subclass
of [`IntegrityError`](#django.db.IntegrityError).

## Exceções Http

Http exceptions may be imported from `django.http`.

### `UnreadablePostError`

#### `exception UnreadablePostError`

[`UnreadablePostError`](#django.http.UnreadablePostError) is raised when a user cancels an upload.

## Exceções de Transações

Transaction exceptions are defined in `django.db.transaction`.

### `TransactionManagementError`

#### `exception TransactionManagementError`

[`TransactionManagementError`](#django.db.transaction.TransactionManagementError) is raised for any and all problems
related to database transactions.

## Testing Framework Exceptions

Exceptions provided by the `django.test` package.

### `RedirectCycleError`

#### `exception client.RedirectCycleError`

[`RedirectCycleError`](#django.test.client.RedirectCycleError) is raised when the test client detects a
loop or an overly long chain of redirects.

## Python Exceções

Django raises built-in Python exceptions when appropriate as well. See the
Python documentation for further information on the [Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#bltin-exceptions).