Django peut aussi bien générer des exceptions qu’il définit lui-même que des exceptions Python standards.
Les classes d’exception de base de Django sont définies dans django.core.exceptions
.
AppRegistryNotReady
¶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
¶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
.
EmptyResultSet
¶EmptyResultSet
[source]¶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
¶MultipleObjectsReturned
¶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
¶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
¶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
¶ViewDoesNotExist
[source]¶L’exception ViewDoesNotExist
est générée par django.urls
lorsqu’une vue demandée n’existe pas.
MiddlewareNotUsed
¶MiddlewareNotUsed
[source]¶L’exception MiddlewareNotUsed
est générée lorsqu’un middleware n’est pas utilisé dans la configuration du serveur.
ImproperlyConfigured
¶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
¶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 :
order_by
non conformes.ValidationError
¶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.
Les exceptions du résolveur d’URL sont définies dans django.urls
.
Resolver404
¶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
¶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.
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.
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.
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
.
Les exceptions HTTP peuvent être importées à partir de django.http
.
UnreadablePostError
¶UnreadablePostError
[source]¶L’exception UnreadablePostError
est générée lorsqu’un utilisateur annule un envoi de fichier.
Les exceptions de transactions sont définies dans django.db.transaction
.
TransactionManagementError
¶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 définies dans le paquet django.test
.
RedirectCycleError
¶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.
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.
mars 30, 2019