--- title: "Exceptions de Django" version: 1.10 locale: fr source: https://docs.djangoproject.com/fr/1.10/ref/exceptions/ canonical: https://djangodocs.dev/fr/1.10/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/1.10/ref/applications/#app-loading-process), qui initialise l’ORM, soit terminé. ### `ObjectDoesNotExist` #### `exception ObjectDoesNotExist` La classe de base des exceptions [`DoesNotExist`](/fr/1.10/ref/models/instances/#django.db.models.Model.DoesNotExist); une clause `try/except` avec `ObjectDoesNotExist` intercepte les exceptions [`DoesNotExist`](/fr/1.10/ref/models/instances/#django.db.models.Model.DoesNotExist) de tous les modèles. Consultez [`get()`](/fr/1.10/ref/models/querysets/#django.db.models.query.QuerySet.get) pour plus d’informations sur les exceptions [`ObjectDoesNotExist`](#django.core.exceptions.ObjectDoesNotExist) et [`DoesNotExist`](/fr/1.10/ref/models/instances/#django.db.models.Model.DoesNotExist). ### `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` L’exception [`MultipleObjectsReturned`](#django.core.exceptions.MultipleObjectsReturned) est générée par une requête lorsqu’un seul objet est attendu mais que la requête renvoie plusieurs objets. Une version de base de cette exception se trouve dans [`django.core.exceptions`](#module-django.core.exceptions); chaque classe de modèle contient une version héritant de cette exception permettant d’identifier précisément le type d’objets renvoyés à plusieurs. Voir [`get()`](/fr/1.10/ref/models/querysets/#django.db.models.query.QuerySet.get) pour plus d’informations. ### `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/1.10/ref/request-response/#django.http.HttpResponseBadRequest). Consultez la [documentation de la journalisation](/fr/1.10/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/1.10/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/1.10/ref/forms/validation/), [Validation des champs de modèle](/fr/1.10/ref/models/instances/#validating-objects) et [Référence de la validation](/fr/1.10/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. ## Exceptions du résolveur d’URL Les exceptions du résolveur d’URL sont définies dans `django.urls`. > **Deprecated since Django 1.10** > > Obsolète depuis la version 1.10: Dans les versions précédentes, ces exceptions se trouvaient dans `django.core.urlresolvers`. L’importation à partir de l’ancien emplacement continuera à fonctionner jusqu’à Django 2.0. ### `Resolver404` #### `exception Resolver404` L’exception [`Resolver404`](#django.urls.Resolver404) est générée par [`django.urls.resolve()`](/fr/1.10/ref/urlresolvers/#django.urls.resolve) si le chemin transmis à `resolve()` ne correspond à aucune vue. C’est une sous-classe de [`django.http.Http404`](/fr/1.10/topics/http/views/#django.http.Http404). ### `NoReverseMatch` #### `exception NoReverseMatch` L’exception [`NoReverseMatch`](#django.urls.NoReverseMatch) est générée par [`django.urls`](/fr/1.10/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 (notez que cet attribut est disponible aussi bien avec Python 2 que Python 3, même si [**PEP 3134**](https://peps.python.org/pep-3134/) ne s’applique normalement qu’à Python 3). Afin d’éviter des différences inattendues avec Python 3, Django s’assure également que l’exception rendue disponible via `__cause__` possède un attribut `__traceback__` exploitable. > **Changed in Django 1.10** > > L’attribut `__traceback__` décrit ci-dessus a été ajouté. #### `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/1.10/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).