Исключения Django¶
Django вызывает некоторые собственные исключения, а также стандартные исключения Python.
Исключения ядра Django¶
Классы исключений ядра Django определены в django.core.exceptions.
AppRegistryNotReady¶
-
exception
AppRegistryNotReady[исходный код]¶ Это исключение возникает при попытке использовать модели до завершения процедуры app loading process, которая инициализирует ORM.
ObjectDoesNotExist¶
-
exception
ObjectDoesNotExist[исходный код]¶ Базовый класс для
Model.DoesNotExistисключений. Классtry/exceptдляObjectDoesNotExistбудет ловитьDoesNotExistисключения для всех моделей.См.
get().
EmptyResultSet¶
-
exception
EmptyResultSet[исходный код]¶ EmptyResultSetможет возникнуть во время генерации запроса, если запрос не вернет никаких результатов. Большинство проектов Django не столкнутся с этим исключением, но оно может быть полезно для реализации пользовательских поисков и выражений.
FieldDoesNotExist¶
-
exception
FieldDoesNotExist[исходный код]¶ Исключение
FieldDoesNotExistвызывается методом_meta.get_field()модели, когда запрашиваемое поле не существует ни в модели, ни в родителях модели.
MultipleObjectsReturned¶
-
exception
MultipleObjectsReturned[исходный код]¶ Базовый класс для
Model.MultipleObjectsReturnedисключений. Классtry/exceptдляMultipleObjectsReturnedбудет ловитьMultipleObjectsReturnedисключения для всех моделей.См.
get().
SuspiciousOperation¶
-
exception
SuspiciousOperation[исходный код]¶ Исключение
SuspiciousOperationвозникает, когда пользователь выполнил операцию, которую следует считать подозрительной с точки зрения безопасности, например, подделка куки сеанса. ПодклассыSuspiciousOperationвключают:DisallowedHostDisallowedModelAdminLookupDisallowedModelAdminToFieldDisallowedRedirectInvalidSessionKeyRequestDataTooBigSuspiciousFileOperationSuspiciousMultipartFormSuspiciousSessionTooManyFieldsSent
Если исключение
SuspiciousOperationдостигает уровня обработчика ASGI/WSGI, оно регистрируется на уровнеErrorи приводит к возникновениюHttpResponseBadRequest. Более подробную информацию см. в logging documentation.
PermissionDenied¶
-
exception
PermissionDenied[исходный код]¶ Исключение
PermissionDeniedвозникает, когда у пользователя нет разрешения на выполнение запрашиваемого действия.
ViewDoesNotExist¶
-
exception
ViewDoesNotExist[исходный код]¶ Исключение
ViewDoesNotExistвызываетсяdjango.urls, когда запрашиваемое представление не существует.
MiddlewareNotUsed¶
-
exception
MiddlewareNotUsed[исходный код]¶ Исключение
MiddlewareNotUsedвозникает, когда промежуточное ПО не используется в конфигурации сервера.
ImproperlyConfigured¶
-
exception
ImproperlyConfigured[исходный код]¶ Исключение
ImproperlyConfiguredвозникает, когда Django каким-то образом неправильно настроен - например, если значение вsettings.pyневерно или не поддается разбору.
FieldError¶
-
exception
FieldError[исходный код]¶ Исключение
FieldErrorвозникает, когда возникает проблема с полем модели. Это может произойти по нескольким причинам:- Поле в модели конфликтует с одноименным полем из абстрактного базового класса
- Бесконечный цикл возникает при заказе
- Ключевое слово не может быть разобрано из параметров фильтра
- Поле не может быть определено по ключевому слову в параметрах запроса
- Объединение не разрешено для указанного поля
- Имя поля является недопустимым
- Запрос содержит недопустимые аргументы order_by
ValidationError¶
-
exception
ValidationError[исходный код]¶ Исключение
ValidationErrorвозникает, когда данные не проходят валидацию полей формы или модели. Подробнее о валидации см. в Form and Field Validation, Model Field Validation и Validator Reference.
RequestAborted¶
-
exception
RequestAborted[исходный код]¶ - New in Django 3.0.
Исключение
RequestAbortedвозникает, когда HTTP-тело, считываемое обработчиком, обрывается на середине пути и клиентское соединение закрывается, или когда клиент не отправляет данные и достигает тайм-аута, при котором сервер закрывает соединение.Он является внутренним для модулей обработчика HTTP, и вы вряд ли увидите его где-либо еще. Если вы модифицируете код обработки HTTP, вам следует вызывать это сообщение, когда вы столкнулись с прерванным запросом, чтобы убедиться, что сокет закрыт чисто.
SynchronousOnlyOperation¶
-
exception
SynchronousOnlyOperation[исходный код]¶ - New in Django 3.0.
Исключение
SynchronousOnlyOperationвозникает, когда код, допустимый только в синхронном коде Python, вызывается из асинхронного контекста (потока с запущенным асинхронным циклом событий). Эти части Django в целом сильно зависят от потокобезопасности для функционирования и не работают корректно в корутинах, разделяющих один и тот же поток.Если вы пытаетесь вызвать код, который является только синхронным, из асинхронного потока, то создайте синхронный поток и вызывайте его в нем. Этого можно добиться с помощью
asgiref.sync.sync_to_async().
Исключения из URL-резольвера¶
Исключения URL Resolver определены в django.urls.
Resolver404¶
-
exception
Resolver404[исходный код]¶ Исключение
Resolver404вызываетсяresolve(), если путь, переданный вresolve(), не отображается на представление. Это подклассdjango.http.Http404.
NoReverseMatch¶
-
exception
NoReverseMatch[исходный код]¶ Исключение
NoReverseMatchвызываетсяdjango.urls, когда подходящий URL в вашей URLconf не может быть идентифицирован на основе предоставленных параметров.
Исключения из базы данных¶
Исключения из базы данных могут быть импортированы из django.db.
Django обертывает стандартные исключения баз данных так, чтобы ваш код Django имел гарантированную общую реализацию этих классов.
-
exception
Error[исходный код]¶
-
exception
InterfaceError[исходный код]¶
-
exception
DatabaseError[исходный код]¶
-
exception
DataError[исходный код]¶
-
exception
OperationalError[исходный код]¶
-
exception
IntegrityError[исходный код]¶
-
exception
InternalError[исходный код]¶
-
exception
ProgrammingError[исходный код]¶
-
exception
NotSupportedError[исходный код]¶
Обертки Django для исключений баз данных ведут себя точно так же, как и базовые исключения баз данных. Более подробную информацию смотрите в PEP 249, спецификация Python Database API Specification v2.0.
Как и в случае PEP 3134, атрибут __cause__ устанавливается с исходным (базовым) исключением базы данных, позволяя получить доступ к любой дополнительной информации.
-
exception
models.ProtectedError¶
Возникает для предотвращения удаления ссылающихся объектов при использовании django.db.models.PROTECT. models.ProtectedError является подклассом IntegrityError.
-
exception
models.RestrictedError¶
Возникает для предотвращения удаления ссылающихся объектов при использовании django.db.models.RESTRICT. models.RestrictedError является подклассом IntegrityError.
Исключения Http¶
Http-исключения могут быть импортированы из django.http.
UnreadablePostError¶
-
exception
UnreadablePostError[исходный код]¶ UnreadablePostErrorвозникает, когда пользователь отменяет загрузку.
Исключения транзакций¶
Исключения транзакций определены в django.db.transaction.
TransactionManagementError¶
-
exception
TransactionManagementError[исходный код]¶ TransactionManagementErrorподнимается для любых и всех проблем, связанных с транзакциями базы данных.
Исключения в системе тестирования¶
Исключения, предоставляемые пакетом django.test.
RedirectCycleError¶
-
exception
client.RedirectCycleError¶ RedirectCycleErrorподнимается, когда тестовый клиент обнаруживает цикл или слишком длинную цепочку перенаправлений.
Исключения в Python¶
Django также поднимает встроенные исключения Python, когда это необходимо. Более подробную информацию о Built-in Exceptions смотрите в документации Python.