Django génère certaines exceptions qui lui sont propres tout comme beaucoup d’exceptions Python standards.
L’exception DoesNotExist est générée lorsqu’aucun objet ne correspond aux paramètres donnés d’une requête.
ObjectDoesNotExist est défini dans django.core.exceptions. DoesNotExist est une sous-classe de l’exception de base ObjectDoesNotExist et est présente pour chaque classe de modèle afin de pouvoir identifier précisément le type d’objet qui n’a pas été trouvé.
Consultez get() pour plus d’informations sur les exceptions ObjectDoesNotExist et DoesNotExist.
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.
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.
L’exception PermissionDenied est générée lorsqu’un utilisateur ne possède pas la permission d’effectuer l’action demandée.
L’exception ViewDoesNotExist est générée par django.core.urlresolvers lorsqu’une vue demandée n’existe pas.
L’exception MiddlewareNotUsed est générée lorsqu’un middleware n’est pas utilisé dans la configuration du serveur.
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.
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.
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.
L’exception NoReverseMatch est générée par django.core.urlresolvers lorsqu’aucune URL contenue dans votre configuration d’URL ne correspond aux paramètres fournis.
Django adapte les exceptions de base de données standard DatabaseError et IntegrityError afin que votre code Django puisse compter sur une implémentation commune de ces classes. Ces exceptions de base de données se trouvent dans django.db.
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.
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. Il s’agit d’une sous-classe de IntegrityError.
L’exception UnreadablePostError est générée lorsqu’un utilisateur annule un envoi de fichier. Elle est disponible dans django.http.
L’exception TransactionManagementError est générée lors de tout problème survenant en lien avec les transactions de bases de données. Elle est disponible dans django.db.transaction.
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 exceptions intégrées.
Jan 13, 2016