Исключения Django ¶
Django может генерировать исключения, которые определяет сам, а также стандартные исключения Python.
Основные исключения Django ¶
Базовые классы исключений Django определены в django.core.exceptions
.
AppRegistryNotReady
¶
-
исключение
AppRegistryNotReady
[источник] ¶ Это исключение создается при попытке использовать шаблоны до завершения процесса загрузки приложения , инициализирующего ORM.
ObjectDoesNotExist
¶
-
исключение
ObjectDoesNotExist
[источник] ¶ Базовый класс исключений
Model.DoesNotExist
. Пунктtry/except
сObjectDoesNotExist
исключениямиDoesNotExist
из всех моделей.Смотрите
get()
.
EmptyResultSet
¶
-
исключение
EmptyResultSet
[источник] ¶ EmptyResultSet
может быть сгенерирован во время построения запроса, если он не возвращает никаких результатов. В большинстве проектов Django это исключение не возникает, но оно может быть полезно для реализации пользовательских запросов или выражений.
FieldDoesNotExist
¶
-
исключение
FieldDoesNotExist
[источник] ¶ Исключение
FieldDoesNotExist
создается методом_meta.get_field()
модели, когда запрошенное поле не существует ни в модели, ни в родительских элементах модели.
MultipleObjectsReturned
¶
-
исключение
MultipleObjectsReturned
[источник] ¶ Базовый класс исключений
Model.MultipleObjectsReturned
. Пунктtry/except
сMultipleObjectsReturned
исключениямиMultipleObjectsReturned
из всех моделей.Смотрите
get()
.
SuspiciousOperation
¶
-
исключение
SuspiciousOperation
[источник] ¶ Исключение
SuspiciousOperation
создается, когда пользователь выполняет операцию, которая считается сомнительной в соответствии с критериями безопасности, например, при обработке сеансового cookie. ПодклассыSuspiciousOperation
включают:DisallowedHost
DisallowedModelAdminLookup
DisallowedModelAdminToField
DisallowedRedirect
InvalidSessionKey
RequestDataTooBig
SuspiciousFileOperation
SuspiciousMultipartForm
SuspiciousSession
TooManyFieldsSent
Если исключение
SuspiciousOperation
достигает уровня обработчика WSGI, оно регистрируется на уровнеError
и выдает исключениеHttpResponseBadRequest
. См. Дополнительную информацию в документации по ведению журнала .
PermissionDenied
¶
-
исключение
PermissionDenied
[источник] ¶ Исключение
PermissionDenied
создается, когда пользователь не имеет разрешения на выполнение запрошенного действия.
ViewDoesNotExist
¶
-
исключение
ViewDoesNotExist
[источник] ¶ Исключение
ViewDoesNotExist
генерируется ,django.urls
когда запрашиваемое представление не существует.
MiddlewareNotUsed
¶
-
исключение
MiddlewareNotUsed
[источник] ¶ Исключение
MiddlewareNotUsed
генерируется, когда промежуточное ПО не используется в конфигурации сервера.
ImproperlyConfigured
¶
-
исключение
ImproperlyConfigured
[источник] ¶ Исключение
ImproperlyConfigured
генерируется, когда конфигурация Django содержит ошибку, например, если значениеsettings.py
неверно или не может быть правильно прочитано.
FieldError
¶
-
исключение
FieldError
[источник] ¶ Исключение
FieldError
создается, когда возникает проблема с полем шаблона. Это может произойти по нескольким причинам:- Поле шаблона конфликтует с одноименным полем абстрактного базового класса.
- Порядок сортировки вызывает бесконечный цикл.
- Ключевое слово не может быть прочитано в параметрах фильтра.
- Невозможно сопоставить именованный параметр запроса с полем.
- Соединение не разрешено в указанном поле.
- Имя поля недействительно.
- Запрос содержит недопустимые параметры
order_by
.
ValidationError
¶
-
исключение
ValidationError
[источник] ¶ Исключение
ValidationError
выдается, когда есть данные, которые не прошли проверку поля формы или модели. Для получения более подробной информации о валидации см валидации форм и полей , полей шаблона проверки и проверки референции .
RequestAborted
¶
-
исключение
RequestAborted
[источник] ¶ - Новое в Django 3.0.
Исключение
RequestAborted
создается, когда тело HTTP-запроса, считываемое обработчиком, преждевременно завершается и клиентское соединение закрывается, или когда клиент не отправляет данные и превышает время, по истечении которого сервер прерывает соединение. подключение.Он является внутренним для модулей управления HTTP и редко встречается где-либо еще. Если вы измените какой-либо код обработки HTTP, вы должны бросить это исключение при обнаружении приостановленного запроса, чтобы убедиться, что соединитель правильно закрыт.
SynchronousOnlyOperation
¶
-
исключение
SynchronousOnlyOperation
[источник] ¶ - Новое в Django 3.0.
Исключение
SynchronousOnlyOperation
возникает, когда код, разрешенный только в контексте синхронного кода Python, вызывается из асинхронного контекста (поток выполнения с выполняющимся асинхронным циклом событий). Эти части Django обычно сильно зависят от изоляции потоков и плохо работают с сопрограммами, которые совместно используют один поток.Если вы пытаетесь вызвать чисто синхронный код из асинхронного потока, создайте синхронный поток и вызовите этот код оттуда. Это можно сделать с помощью
asgiref.sync.sync_to_async()
.
Исключения преобразователя URL ¶
Исключения преобразователя URL определены в django.urls
.
Resolver404
¶
-
исключение
Resolver404
¶ Исключение
Resolver404
выдается,django.urls.resolve()
если путь, переданный вresolve()
, не соответствует ни одному представлению. Это подклассdjango.http.Http404
.
NoReverseMatch
¶
-
исключение
NoReverseMatch
¶ Исключение
NoReverseMatch
создается,django.urls
когда ни один URL-адрес, содержащийся в вашей конфигурации URL-адреса, не соответствует предоставленным параметрам.
Исключения базы данных ¶
Исключения базы данных можно импортировать из файлов django.db
.
Django адаптирует стандартные исключения базы данных, чтобы ваш код Django мог полагаться на общую реализацию этих классов.
-
исключение
Error
¶
-
исключение
InterfaceError
¶
-
исключение
DatabaseError
¶
-
исключение
DataError
¶
-
исключение
OperationalError
¶
-
исключение
IntegrityError
¶
-
исключение
InternalError
¶
-
исключение
ProgrammingError
¶
-
исключение
NotSupportedError
¶
Адаптеры Django для этих исключений базы данных ведут себя точно так же, как и их базовые исключения. Проконсультируйтесь сPEP 249 , версия 2.0 спецификации Python Database API, для получения дополнительной информации.
В соответствии с PEP 3134 , атрибут__cause__
определяется с базовым исключением базы данных, что позволяет получить доступ к любой дополнительной информации.
-
исключение
models.
ProtectedError
¶
Это исключение создается для предотвращения удаления связанных объектов при использовании django.db.models.PROTECT
. models.ProtectedError
является подклассом IntegrityError
.
-
исключение
models.
RestrictedError
¶
Поднят для предотвращения удаления объектов, на которые есть ссылки, при использовании
django.db.models.RESTRICT
. models.RestrictedError
является подклассом IntegrityError
.
Исключения http ¶
Исключения HTTP можно импортировать из файлов django.http
.
UnreadablePostError
¶
-
исключение
UnreadablePostError
¶ Исключение
UnreadablePostError
создается, когда пользователь отменяет загрузку файла.
Исключения транзакций ¶
Исключения транзакций определены в django.db.transaction
.
TransactionManagementError
¶
-
исключение
TransactionManagementError
¶ Исключение
TransactionManagementError
генерируется, когда возникает какая-либо проблема в связи с транзакциями базы данных.
Исключения из тестовой инфраструктуры ¶
Исключения, определенные в пакете django.test
.
RedirectCycleError
¶
-
исключение
client.
RedirectCycleError
¶ Исключение
RedirectCycleError
генерируется, когда тестовый клиент обнаруживает слишком длинный цикл или цепочку перенаправления.
Исключения Python ¶
Django также при необходимости генерирует встроенные исключения Python. См. Документацию Python для получения дополнительной информации о встроенных исключениях .