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[source]

Cette exception est générée lorsqu’on essaie d’utiliser des modèles avant que le processus de chargement des applications, qui initialise l’ORM, soit terminé.

ObjectDoesNotExist

exception ObjectDoesNotExist[source]

La classe de base des exceptions DoesNotExist; une clause try/except avec ObjectDoesNotExist intercepte les exceptions DoesNotExist de tous les modèles.

Consultez get() pour plus d’informations sur les exceptions ObjectDoesNotExist et DoesNotExist.

FieldDoesNotExist

exception FieldDoesNotExist[source]

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[source]

L’exception 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; 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() pour plus d’informations.

SuspiciousOperation

exception SuspiciousOperation[source]

L’exception 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. Consultez la documentation de la journalisation pour plus d’informations.

PermissionDenied

exception PermissionDenied[source]

L’exception PermissionDenied est générée lorsqu’un utilisateur ne possède pas la permission d’effectuer l’action demandée.

ViewDoesNotExist

exception ViewDoesNotExist[source]

L’exception ViewDoesNotExist est générée par django.urls lorsqu’une vue demandée n’existe pas.

MiddlewareNotUsed

exception MiddlewareNotUsed[source]

L’exception MiddlewareNotUsed est générée lorsqu’un middleware n’est pas utilisé dans la configuration du serveur.

ImproperlyConfigured

exception ImproperlyConfigured[source]

L’exception 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[source]

L’exception 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[source]

L’exception 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, Validation des champs de modèle et Référence de la validation.

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.

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[source]

L’exception Resolver404 est générée par django.urls.resolve() si le chemin transmis à resolve() ne correspond à aucune vue. C’est une sous-classe de django.http.Http404.

NoReverseMatch

exception NoReverseMatch[source]

L’exception NoReverseMatch est générée par 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[source]
exception InterfaceError[source]
exception DatabaseError[source]
exception DataError[source]
exception OperationalError[source]
exception IntegrityError[source]
exception InternalError[source]
exception ProgrammingError[source]
exception NotSupportedError[source]

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, 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, 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 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. models.ProtectedError est une sous-classe de IntegrityError.

Exceptions Http

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

UnreadablePostError

exception UnreadablePostError[source]

L’exception 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[source]

L’exception 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 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.

Back to Top