---
title: "Exceptions de Django"
version: 3.0
locale: fr
source: https://docs.djangoproject.com/fr/3.0/ref/exceptions/
canonical: https://djangodocs.dev/fr/3.0/ref/exceptions/
---
# Exceptions de Django

Django peut aussi bien générer des exceptions qu’il définit lui-même que des exceptions Python standards.

## Exceptions principales de Django

Les classes d’exception de base de Django sont définies dans `django.core.exceptions`.

### `AppRegistryNotReady`

#### `exception AppRegistryNotReady`

Cette exception est générée lorsqu’on essaie d’utiliser des modèles avant que le [processus de chargement des applications](/fr/3.0/ref/applications/#app-loading-process), qui initialise l’ORM, soit terminé.

### `ObjectDoesNotExist`

#### `exception ObjectDoesNotExist`

La classe de base des exceptions [`Model.DoesNotExist`](/fr/3.0/ref/models/class/#django.db.models.Model.DoesNotExist). Une clause `try/except` avec `ObjectDoesNotExist` intercepte les exceptions [`DoesNotExist`](/fr/3.0/ref/models/class/#django.db.models.Model.DoesNotExist) de tous les modèles.

Voir [`get()`](/fr/3.0/ref/models/querysets/#django.db.models.query.QuerySet.get).

### `EmptyResultSet`

#### `exception EmptyResultSet`

`EmptyResultSet` peut être généré durant la construction de la requête si celle-ci ne renvoie aucun résultat. La plupart des projets Django ne rencontreront pas cette exception, mais elle peut être utile pour implémenter des interrogations ou des expressions personnalisées.

### `FieldDoesNotExist`

#### `exception FieldDoesNotExist`

L’exception `FieldDoesNotExist` est produite par une méthode `_meta.get_field()` d’un modèle lorsque le champ demandé n’existe pas dans le modèle, ni dans les parents du modèle.

### `MultipleObjectsReturned`

#### `exception MultipleObjectsReturned`

La classe de base des exceptions [`Model.MultipleObjectsReturned`](/fr/3.0/ref/models/class/#django.db.models.Model.MultipleObjectsReturned). Une clause `try/except` avec `MultipleObjectsReturned` intercepte les exceptions [`MultipleObjectsReturned`](/fr/3.0/ref/models/class/#django.db.models.Model.MultipleObjectsReturned) de tous les modèles.

Voir [`get()`](/fr/3.0/ref/models/querysets/#django.db.models.query.QuerySet.get).

### `SuspiciousOperation`

#### `exception SuspiciousOperation`

L’exception [`SuspiciousOperation`](#django.core.exceptions.SuspiciousOperation) est générée lorsqu’un utilisateur effectue une opération considérée comme douteuse selon des critères de sécurité, comme lors de manipulations d’un cookie de session. Les sous-classes de `SuspiciousOperation` comprennent :

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

Si une exception `SuspiciousOperation` atteint le niveau du gestionnaire WSGI, elle est journalisée au niveau `Error` et produit une exception [`HttpResponseBadRequest`](/fr/3.0/ref/request-response/#django.http.HttpResponseBadRequest). Consultez la [documentation de la journalisation](/fr/3.0/topics/logging/) pour plus d’informations.

### `PermissionDenied`

#### `exception PermissionDenied`

L’exception [`PermissionDenied`](#django.core.exceptions.PermissionDenied) est générée lorsqu’un utilisateur ne possède pas la permission d’effectuer l’action demandée.

### `ViewDoesNotExist`

#### `exception ViewDoesNotExist`

L’exception [`ViewDoesNotExist`](#django.core.exceptions.ViewDoesNotExist) est générée par [`django.urls`](/fr/3.0/ref/urlresolvers/#module-django.urls) lorsqu’une vue demandée n’existe pas.

### `MiddlewareNotUsed`

#### `exception MiddlewareNotUsed`

L’exception [`MiddlewareNotUsed`](#django.core.exceptions.MiddlewareNotUsed) est générée lorsqu’un middleware n’est pas utilisé dans la configuration du serveur.

### `ImproperlyConfigured`

#### `exception ImproperlyConfigured`

L’exception [`ImproperlyConfigured`](#django.core.exceptions.ImproperlyConfigured) est générée lorsque la configuration de Django contient une erreur, par exemple si une valeur de `settings.py` n’est pas correcte ou ne peut pas être lue correctement.

### `FieldError`

#### `exception FieldError`

L’exception [`FieldError`](#django.core.exceptions.FieldError) est générée lorsqu’il y a un problème avec un champ de modèle. Ceci peut arriver pour plusieurs raisons :

- Un champ de modèle est en conflit avec un champ de même nom provenant d’une classe de base abstraite.
- Un ordre de tri provoque une boucle sans fin.
- Un mot-clé ne peut pas être lu dans les paramètres d’un filtre.
- Il n’est pas possible de faire correspondre un paramètre nommé d’une requête avec un champ.
- Une jointure n’est pas autorisée sur le champ indiqué.
- Un nom de champ n’est pas valide.
- Une requête contient des paramètres `order_by` non conformes.

### `ValidationError`

#### `exception ValidationError`

L’exception [`ValidationError`](#django.core.exceptions.ValidationError) est générée lorsque des données font échouer la validation de formulaire ou de champ de modèle. Pour plus d’informations sur la validation, consultez [Validation des formulaires et des champs](/fr/3.0/ref/forms/validation/), [Validation des champs de modèle](/fr/3.0/ref/models/instances/#validating-objects) et [Référence de la validation](/fr/3.0/ref/validators/).

#### `NON_FIELD_ERRORS`

#### `NON_FIELD_ERRORS`

Les exceptions `ValidationError` qui ne sont pas liées à un champ particulier d’un formulaire ou d’un modèle sont classées comme `NON_FIELD_ERRORS`. Cette constante est utilisée comme clé dans des dictionnaires qui habituellement font correspondre des champs à leur liste d’erreurs respective.

### `RequestAborted`

#### `exception RequestAborted`

> **New in Django 3.0**

L’exception [`RequestAborted`](#django.core.exceptions.RequestAborted) est produite lorsqu’un corps de requête HTTP en cours de lecture par le gestionnaire est interrompu prématurément et que la connexion cliente est fermée, ou quand le client n’envoie pas de données et dépasse le délai après lequel le serveur coupe la connexion.

Elle est interne aux modules de gestion HTTP et il est rare de la voir ailleurs. SI vous modifiez du code de gestion HTTP, vous devriez générer cette exception lorsque vous êtes confronté à une requête interrompue pour être sûr que le connecteur soit proprement fermé.

### `SynchronousOnlyOperation`

#### `exception SynchronousOnlyOperation`

> **New in Django 3.0**

L’exception [`SynchronousOnlyOperation`](#django.core.exceptions.SynchronousOnlyOperation) est générée lorsque du code qui n’est autorisé que dans un contexte de code Python synchrone est appelé à partir d’un contexte asynchrone (un fil d’exécution avec une boucle événementielle asynchrone en cours). Ces parties de Django sont généralement fortement dépendantes de l’isolation des fils d’exécution pour fonctionner et ne fonctionnent pas correctement avec des coroutines qui partagent un même fil d’exécution.

Si vous essayez d’appeler du code qui est purement synchrone à partir d’un fil d’exécution asynchrone, créez un fil d’exécution synchrone et appelez ce code depuis là. Ceci peut se faire à l’aide de [`asgiref.sync.sync_to_async()`](/fr/3.0/topics/async/#asgiref.sync.sync_to_async).

## Exceptions du résolveur d’URL

Les exceptions du résolveur d’URL sont définies dans `django.urls`.

### `Resolver404`

#### `exception Resolver404`

L’exception [`Resolver404`](#django.urls.Resolver404) est générée par [`django.urls.resolve()`](/fr/3.0/ref/urlresolvers/#django.urls.resolve) si le chemin transmis à `resolve()` ne correspond à aucune vue. C’est une sous-classe de [`django.http.Http404`](/fr/3.0/topics/http/views/#django.http.Http404).

### `NoReverseMatch`

#### `exception NoReverseMatch`

L’exception [`NoReverseMatch`](#django.urls.NoReverseMatch) est générée par [`django.urls`](/fr/3.0/ref/urlresolvers/#module-django.urls) lorsqu’aucune URL contenue dans votre configuration d’URL ne correspond aux paramètres fournis.

## Exceptions de base de données

Les exceptions de base de données peuvent être importées à partir de `django.db`.

Django adapte les exceptions de base de données standard afin que votre code Django puisse compter sur une implémentation commune de ces classes.

#### `exception Error`

#### `exception InterfaceError`

#### `exception DatabaseError`

#### `exception DataError`

#### `exception OperationalError`

#### `exception IntegrityError`

#### `exception InternalError`

#### `exception ProgrammingError`

#### `exception NotSupportedError`

Les adaptateurs Django de ces exceptions de base de données se comportent exactement de la même manière que leurs exceptions sous-jacentes. Consultez la [**PEP 249**](https://peps.python.org/pep-0249/), la version 2.0 de la spécification Python d’API de base de données,  pour de plus amples informations.

Se conformant à [**PEP 3134**](https://peps.python.org/pep-3134/), un attribut `__cause__` est défini avec l’exception de base de données sous-jacente, permettant ainsi d’avoir accès à d’éventuelles informations complémentaires.

#### `exception models.ProtectedError`

Cette exception est générée pour empêcher la suppression d’objets référencés lors de l’utilisation de [`django.db.models.PROTECT`](/fr/3.0/ref/models/fields/#django.db.models.PROTECT). [`models.ProtectedError`](#django.db.models.ProtectedError) est une sous-classe de [`IntegrityError`](#django.db.IntegrityError).

## Exceptions Http

Les exceptions HTTP peuvent être importées à partir de `django.http`.

### `UnreadablePostError`

#### `exception UnreadablePostError`

L’exception [`UnreadablePostError`](#django.http.UnreadablePostError) est générée lorsqu’un utilisateur annule un envoi de fichier.

## Exceptions de transaction

Les exceptions de transactions sont définies dans `django.db.transaction`.

### `TransactionManagementError`

#### `exception TransactionManagementError`

L’exception [`TransactionManagementError`](#django.db.transaction.TransactionManagementError) est générée lors de tout problème survenant en lien avec les transactions de bases de données.

## Exceptions de l’infrastructure de test

Exceptions définies dans le paquet `django.test`.

### `RedirectCycleError`

#### `exception client.RedirectCycleError`

L’exception [`RedirectCycleError`](#django.test.client.RedirectCycleError) est générée lorsque le client de test détecte une boucle ou une chaîne de redirection trop longue.

## Exceptions Python

Django génère également des exceptions intégrées de Python le cas échéant. Consultez la documentation de Python pour plus d’informations concernant les [Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#bltin-exceptions).
