Django tar upp några av sina egna undantag samt standard Python-undantag.
\nDjango core undantagsklasser definieras i django.core.exceptions.
AppRegistryNotReadyLink to this heading#Detta undantag uppstår när man försöker använda modeller innan app loading process, som initierar ORM, är klar.
\nObjektDoesNotExistLink to this heading#Basklassen för Model.DoesNotExist undantag. En try/except för ObjectDoesNotExist kommer att fånga DoesNotExist undantag för alla modeller.
See get().
ObjectNotUpdatedLink to this heading#The base class for Model.NotUpdated exceptions. A try/except for\nObjectNotUpdated will catch\nNotUpdated exceptions for all models.
See save().
EmptyResultSetLink to this heading#EmptyResultSet kan uppstå under frågegenereringen om en fråga inte kommer att returnera några resultat. De flesta Django-projekt kommer inte att stöta på detta undantag, men det kan vara användbart för att implementera anpassade uppslagningar och uttryck.
Full resultatuppsättningLink to this heading#FullResultSet kan uppstå under frågegenereringen om en fråga kommer att matcha allt. De flesta Django-projekt kommer inte att stöta på detta undantag, men det kan vara användbart för att implementera anpassade uppslagningar och uttryck.
FieldDoesNotExistLink to this heading#Undantaget FieldDoesNotExist skapas av en modells metod _meta.get_field() när det begärda fältet inte finns i modellen eller i modellens föräldrar.
Flera objekt återlämnadeLink to this heading#Basklassen för Model.MultipleObjectsReturned undantag. En try/except för MultipleObjectsReturned kommer att fånga MultipleObjectsReturned undantag för alla modeller.
See get().
Undantaget SuspiciousOperation uppstår när en användare har utfört en åtgärd som bör betraktas som misstänkt ur ett säkerhetsperspektiv, t.ex. manipulering av en sessionskaka. Underklasser till SuspiciousOperation inkluderar:
DisallowedHost
DisallowedModelAdminLookup
DisallowedModelAdminToField
DisallowedRedirect
ogiltig sessionsnyckel
”Begäran om uppgifter alltför stor
”Misstänkt filhantering
”Misstänksamt flerdelat formulär
”Misstänkt session
TooManyFieldsSent
TooManyFilesSent
Om ett undantag från SuspiciousOperation når ASGI/WSGI-hanterarnivån loggas det på Error-nivån och resulterar i en HttpResponseBadRequest. Se logging documentation för mer information.
PermissionDeniedLink to this heading#Undantaget PermissionDenied uppstår när en användare inte har behörighet att utföra den begärda åtgärden.
ViewDoesNotExistLink to this heading#Undantaget ViewDoesNotExist tas upp av django.urls när en begärd vy inte finns.
MiddlewareNotUsedLink to this heading#Undantaget MiddlewareNotUsed uppstår när en middleware inte används i serverkonfigurationen.
Undantaget ImproperlyConfigured uppstår när Django på något sätt är felaktigt konfigurerat - till exempel om ett värde i settings.py är felaktigt eller omöjligt att separera.
FieldErrorLink to this heading#Undantaget FieldError uppstår när det finns ett problem med ett modellfält. Detta kan inträffa av flera skäl:
Ett fält i en modell krockar med ett fält med samma namn från en abstrakt basklass
En oändlig loop orsakas av att man beställer
Ett nyckelord kan inte tolkas från filterparametrarna
Ett fält kan inte bestämmas utifrån ett nyckelord i frågeparametrarna
En join är inte tillåten på det angivna fältet
Ett fältnamn är ogiltigt
En fråga innehåller ogiltiga order_by-argument
ValideringsfelLink to this heading#Undantaget ValidationError uppstår när data inte klarar validering av formulär eller modellfält. Mer information om validering finns i Form and Field Validation, Model Field Validation och Validator Reference.
”ValidationError” som inte hör till ett visst fält i ett formulär eller en modell klassificeras som ”Non_field_errors”. Denna konstant används som en nyckel i ordböcker som annars mappar fält till deras respektive lista över fel.
\nBadRequestLink to this heading#Undantaget BadRequest uppstår när begäran inte kan behandlas på grund av ett klientfel. Om ett BadRequest undantag når ASGI/WSGI hanterarnivå resulterar det i en HttpResponseBadRequest.
Beställning avbrutenLink to this heading#Undantaget RequestAborted uppstår när en HTTP-kropp som läses in av hanteraren avbryts mitt i processen och klientanslutningen stängs, eller när klienten inte skickar data och når en timeout där servern stänger anslutningen.
Den är intern för HTTP-hanteringsmodulerna och det är osannolikt att du kommer att se den någon annanstans. Om du ändrar HTTP-hanteringskoden bör du ta upp detta när du stöter på en avbruten begäran för att se till att sockeln stängs på ett snyggt sätt.
\nSynkronOnlyOperationLink to this heading#Undantaget SynchronousOnlyOperation uppstår när kod som endast är tillåten i synkron Python-kod anropas från ett asynkront sammanhang (en tråd med en asynkron händelseslinga som körs). Dessa delar av Django är i allmänhet starkt beroende av tråd-säkerhet för att fungera och fungerar inte korrekt under coroutines som delar samma tråd.
Om du försöker anropa kod som endast är synkron från en asynkron tråd, skapa då en synkron tråd och anropa den i den. Du kan åstadkomma detta med asgiref.sync.sync_to_async().
Undantag för URL-resolver definieras i django.urls.
Resolver404Link to this heading#The Resolver404 exception is raised by\nresolve() if the path passed to resolve() doesn’t\nmap to a view. It’s a subclass of django.http.Http404.
NoReverseMatchLink to this heading#Undantaget NoReverseMatch skapas av django.urls när en matchande URL i din URLconf inte kan identifieras baserat på de parametrar som anges.
Databasundantag kan importeras från django.db.
Django omsluter standarddatabasundantagen så att din Django-kod har en garanterad gemensam implementering av dessa klasser.
\nDjango wrappers för databasundantag beter sig exakt likadant som de underliggande databasundantagen. Se PEP 249, Python Database API Specification v2.0, för ytterligare information.
\nEnligt PEP 3134 sätts ett __cause__-attribut med det ursprungliga (underliggande) databasundantaget, vilket ger tillgång till ytterligare information som tillhandahålls.
Utlöses för att förhindra radering av refererade objekt när django.db.models.PROTECT används. models.ProtectedError är en underklass till IntegrityError.
Utlöses för att förhindra radering av refererade objekt när django.db.models.RESTRICT används. models.RestrictedError är en underklass till IntegrityError.
HTTP-undantag kan importeras från django.http.
OläsligtPostFelLink to this heading#UnreadablePostError uppstår när en användare avbryter en uppladdning.
Sessionsundantag definieras i django.contrib.sessions.exceptions.
Session avbrutenLink to this heading#SessionInterrupted tas upp när en session förstörs i en samtidig begäran. Det är en underklass av BadRequest.
Transaktionsundantag definieras i django.db.transaction.
TransactionManagementErrorLink to this heading#TransactionManagementError uppstår vid alla problem som har med databastransaktioner att göra.
Undantag som tillhandahålls av paketet django.test.
RedirectCycleErrorLink to this heading#RedirectCycleError uppstår när testklienten upptäcker en loop eller en alltför lång kedja av omdirigeringar.
Django tar också upp inbyggda Python-undantag när det är lämpligt. Se Python-dokumentationen för ytterligare information om Built-in Exceptions.
\n