---
title: "Django Undantag"
version: 6.1
locale: sv
source: https://docs.djangoproject.com/sv/6.1/ref/exceptions/
canonical: https://djangodocs.dev/sv/6.1/ref/exceptions/
---
# Django Undantag

Django tar upp några av sina egna undantag samt standard Python-undantag.

## Django Core Undantag

Django core undantagsklasser definieras i `django.core.exceptions`.

### `AppRegistryNotReady`

#### `exception AppRegistryNotReady`

Detta undantag uppstår när man försöker använda modeller innan [app loading process](/sv/6.1/ref/applications/#app-loading-process), som initierar ORM, är klar.

### `ObjektDoesNotExist`

#### `exception ObjectDoesNotExist`

Basklassen för [`Model.DoesNotExist`](/sv/6.1/ref/models/class/#django.db.models.Model.DoesNotExist) undantag. En `try/except` för `ObjectDoesNotExist` kommer att fånga [`DoesNotExist`](/sv/6.1/ref/models/class/#django.db.models.Model.DoesNotExist) undantag för alla modeller.

See [`get()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.get).

### `ObjectNotUpdated`

> **New in Django 6.0**

#### `exception ObjectNotUpdated`

The base class for [`Model.NotUpdated`](/sv/6.1/ref/models/class/#django.db.models.Model.NotUpdated) exceptions. A `try/except` for
`ObjectNotUpdated` will catch
[`NotUpdated`](/sv/6.1/ref/models/class/#django.db.models.Model.NotUpdated) exceptions for all models.

See [`save()`](/sv/6.1/ref/models/instances/#django.db.models.Model.save).

### `EmptyResultSet`

#### `exception EmptyResultSet`

`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ättning`

#### `exception FullResultSet`

`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.

### `FieldDoesNotExist`

#### `exception FieldDoesNotExist`

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ämnade`

#### `exception MultipleObjectsReturned`

Basklassen för [`Model.MultipleObjectsReturned`](/sv/6.1/ref/models/class/#django.db.models.Model.MultipleObjectsReturned) undantag. En `try/except` för `MultipleObjectsReturned` kommer att fånga [`MultipleObjectsReturned`](/sv/6.1/ref/models/class/#django.db.models.Model.MultipleObjectsReturned) undantag för alla modeller.

See [`get()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.get).

### ”Misstänkta operationer

#### `exception SuspiciousOperation`

Undantaget [`SuspiciousOperation`](#django.core.exceptions.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`](/sv/6.1/ref/request-response/#django.http.HttpResponseBadRequest). Se [logging documentation](/sv/6.1/topics/logging/) för mer information.

### `PermissionDenied`

#### `exception PermissionDenied`

Undantaget [`PermissionDenied`](#django.core.exceptions.PermissionDenied) uppstår när en användare inte har behörighet att utföra den begärda åtgärden.

### `ViewDoesNotExist`

#### `exception ViewDoesNotExist`

Undantaget [`ViewDoesNotExist`](#django.core.exceptions.ViewDoesNotExist) tas upp av [`django.urls`](/sv/6.1/ref/urlresolvers/#module-django.urls) när en begärd vy inte finns.

### `MiddlewareNotUsed`

#### `exception MiddlewareNotUsed`

Undantaget [`MiddlewareNotUsed`](#django.core.exceptions.MiddlewareNotUsed) uppstår när en middleware inte används i serverkonfigurationen.

### ”Korrekt konfigurerad

#### `exception ImproperlyConfigured`

Undantaget [`ImproperlyConfigured`](#django.core.exceptions.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.

### `FieldError`

#### `exception FieldError`

Undantaget [`FieldError`](#django.core.exceptions.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

### `FieldFetchBlocked`

> **New in Django 6.1**

#### `exception FieldFetchBlocked`

Raised when a field would be fetched on-demand and the
[`FETCH_RAISE`](/sv/6.1/topics/db/fetch-modes/#django.db.models.FETCH_RAISE) fetch mode is active.

### `Valideringsfel`

#### `exception ValidationError`

Undantaget [`ValidationError`](#django.core.exceptions.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](/sv/6.1/ref/forms/validation/), [Model Field Validation](/sv/6.1/ref/models/instances/#validating-objects) och [Validator Reference](/sv/6.1/ref/validators/).

#### fEL SOM INTE ÄR FÄLTFEL

#### `NON_FIELD_ERRORS`

”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.

### `BadRequest`

#### `exception BadRequest`

Undantaget [`BadRequest`](#django.core.exceptions.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`](/sv/6.1/ref/request-response/#django.http.HttpResponseBadRequest).

### `Beställning avbruten`

#### `exception RequestAborted`

Undantaget [`RequestAborted`](#django.core.exceptions.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.

### `SynkronOnlyOperation`

#### `exception SynchronousOnlyOperation`

Undantaget [`SynchronousOnlyOperation`](#django.core.exceptions.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()`](/sv/6.1/topics/async/#asgiref.sync.sync_to_async).

## Undantag för URL-resolver

Undantag för URL-resolver definieras i `django.urls`.

### `Resolver404`

#### `exception Resolver404`

The [`Resolver404`](#django.urls.Resolver404) exception is raised by
[`resolve()`](/sv/6.1/ref/urlresolvers/#django.urls.resolve) if the path passed to `resolve()` doesn’t
map to a view. It’s a subclass of [`django.http.Http404`](/sv/6.1/topics/http/views/#django.http.Http404).

### `NoReverseMatch`

#### `exception NoReverseMatch`

Undantaget [`NoReverseMatch`](#django.urls.NoReverseMatch) skapas av [`django.urls`](/sv/6.1/ref/urlresolvers/#module-django.urls) när en matchande URL i din URLconf inte kan identifieras baserat på de parametrar som anges.

## Databasundantag

Databasundantag kan importeras från `django.db`.

Django omsluter standarddatabasundantagen så att din Django-kod har en garanterad gemensam implementering av dessa klasser.

#### `exception Error`

#### `exception InterfaceError`

#### `exception DatabaseError`

#### `exception DataError`

#### `exception OperationalError`

#### `exception IntegrityError`

#### `exception InternalError`

#### `exception ProgrammingError`

#### `exception NotSupportedError`

Django wrappers för databasundantag beter sig exakt likadant som de underliggande databasundantagen. Se [**PEP 249**](https://peps.python.org/pep-0249/), Python Database API Specification v2.0, för ytterligare information.

A [`__cause__`](https://docs.python.org/3/library/exceptions.html#BaseException.__cause__) attribute is set with the original
(underlying) database exception, allowing access to any additional information
provided.

#### `exception models.ProtectedError`

Utlöses för att förhindra radering av refererade objekt när [`django.db.models.PROTECT`](/sv/6.1/ref/models/fields/#django.db.models.PROTECT) används. [`models.ProtectedError`](#django.db.models.ProtectedError) är en underklass till [`IntegrityError`](#django.db.IntegrityError).

#### `exception models.RestrictedError`

Utlöses för att förhindra radering av refererade objekt när [`django.db.models.RESTRICT`](/sv/6.1/ref/models/fields/#django.db.models.RESTRICT) används. [`models.RestrictedError`](#django.db.models.RestrictedError) är en underklass till [`IntegrityError`](#django.db.IntegrityError).

## HTTP-undantag

HTTP-undantag kan importeras från `django.http`.

### `OläsligtPostFel`

#### `exception UnreadablePostError`

[`UnreadablePostError`](#django.http.UnreadablePostError) uppstår när en användare avbryter en uppladdning.

## Undantag för sessioner

Sessionsundantag definieras i `django.contrib.sessions.exceptions`.

### `Session avbruten`

#### `exception SessionInterrupted`

[`SessionInterrupted`](#django.contrib.sessions.exceptions.SessionInterrupted) tas upp när en session förstörs i en samtidig begäran. Det är en underklass av [`BadRequest`](#django.core.exceptions.BadRequest).

## Undantag för transaktioner

Transaktionsundantag definieras i `django.db.transaction`.

### `TransactionManagementError`

#### `exception TransactionManagementError`

[`TransactionManagementError`](#django.db.transaction.TransactionManagementError) uppstår vid alla problem som har med databastransaktioner att göra.

## Undantag i testramverket

Undantag som tillhandahålls av paketet `django.test`.

### `RedirectCycleError`

#### `exception client.RedirectCycleError`

[`RedirectCycleError`](#django.test.client.RedirectCycleError) uppstår när testklienten upptäcker en loop eller en alltför lång kedja av omdirigeringar.

## Python-undantag

Django tar också upp inbyggda Python-undantag när det är lämpligt. Se Python-dokumentationen för ytterligare information om [Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#bltin-exceptions).
