Исключения Django ¶
Django вызывает некоторые собственные исключения, а также стандартные исключения Python.
Исключения Django Core ¶
Основные классы исключений Django определены в django.core.exceptions
.
AppRegistryNotReady
¶
-
исключение
AppRegistryNotReady
[источник] ¶ Это исключение возникает при попытке использовать модели до завершения процесса загрузки приложения , который инициализирует ORM.
ObjectDoesNotExist
¶
-
исключение
ObjectDoesNotExist
[источник] ¶ Базовый класс для
Model.DoesNotExist
исключений. Аtry/except
forObjectDoesNotExist
будет ловитьDoesNotExist
исключения для всех моделей.Смотрите
get()
.
EmptyResultSet
¶
-
исключение
EmptyResultSet
[источник] ¶ EmptyResultSet
может быть поднят во время генерации запроса, если запрос не вернет никаких результатов. В большинстве проектов Django это исключение не встречается, но оно может быть полезно для реализации пользовательских поисков и выражений.
FieldDoesNotExist
¶
-
исключение
FieldDoesNotExist
[источник] ¶ FieldDoesNotExist
Возбуждаются исключение модели с_meta.get_field()
методом , когда запрашиваемое поле не существует на модели или на родителях модели.
MultipleObjectsReturned
¶
-
исключение
MultipleObjectsReturned
[источник] ¶ Базовый класс для
Model.MultipleObjectsReturned
исключений. Аtry/except
forMultipleObjectsReturned
будет ловитьMultipleObjectsReturned
исключения для всех моделей.Смотрите
get()
.
SuspiciousOperation
¶
-
исключение
SuspiciousOperation
[источник] ¶ SuspiciousOperation
Исключение возникает , когда пользователь выполнил операцию , которую следует считать подозрительной с точки зрения безопасности, такими как Подмена куки сессии. ПодклассыSuspiciousOperation
включают:DisallowedHost
DisallowedModelAdminLookup
DisallowedModelAdminToField
DisallowedRedirect
InvalidSessionKey
RequestDataTooBig
SuspiciousFileOperation
SuspiciousMultipartForm
SuspiciousSession
TooManyFieldsSent
Если
SuspiciousOperation
исключение достигает уровня обработчика ASGI / WSGI, оно регистрируется наError
уровне и приводит к созданию файлаHttpResponseBadRequest
. Дополнительную информацию см. В документации по ведению журнала .
PermissionDenied
¶
-
исключение
PermissionDenied
[источник] ¶ PermissionDenied
Исключение возникает , когда пользователь не имеет разрешения на выполнение действия , запрошенное.
ViewDoesNotExist
¶
-
исключение
ViewDoesNotExist
[источник] ¶ ViewDoesNotExist
Возбуждается исключение ,django.urls
если запрошенный представление не существует.
MiddlewareNotUsed
¶
-
исключение
MiddlewareNotUsed
[источник] ¶ MiddlewareNotUsed
Возбуждается исключение , когда промежуточное программное обеспечение не используется в конфигурации сервера.
ImproperlyConfigured
¶
-
исключение
ImproperlyConfigured
[источник] ¶ ImproperlyConfigured
Возбуждается исключение , когда Джанго каким - то образом настроен неправильно - например, если значение вsettings.py
неправильно или не поддается синтаксическому анализу.
FieldError
¶
-
исключение
FieldError
[источник] ¶ FieldError
Исключение возникает , когда возникает проблема с полем модели. Это может произойти по нескольким причинам:- Поле в модели конфликтует с одноименным полем абстрактного базового класса.
- Бесконечный цикл вызван упорядочиванием
- Ключевое слово не может быть проанализировано из параметров фильтра
- Поле не может быть определено по ключевому слову в параметрах запроса
- Соединение не разрешено в указанном поле
- Имя поля недействительно
- Запрос содержит недопустимые аргументы order_by
ValidationError
¶
-
исключение
ValidationError
[источник] ¶ ValidationError
Возбуждается исключение , когда данные не удается формы или модели поля проверки. Дополнительные сведения о проверке подлинности см Форма и поля Validation , модельное поле Проверка и валидатора .
BadRequest
¶
-
исключение
BadRequest
[источник] ¶ - Новое в Django 3.2.
BadRequest
Возбуждается исключение , когда запрос не может быть обработан из - за ошибки клиента. ЕслиBadRequest
исключение достигает уровня обработчика ASGI / WSGI, оно приводит к возникновению файлаHttpResponseBadRequest
.
RequestAborted
¶
-
исключение
RequestAborted
[источник] ¶ RequestAborted
Исключение возникает , когда HTTP тело читается в обработчиком отрезан переправе и закрывает соединение клиента, или если клиент не передает данные и попадает тайм - аут , когда сервер закрывает соединение.Он является внутренним для модулей обработчика HTTP, и вы вряд ли увидите его где-либо еще. Если вы изменяете код обработки HTTP, вы должны поднять это значение при обнаружении прерванного запроса, чтобы убедиться, что сокет полностью закрыт.
SynchronousOnlyOperation
¶
-
исключение
SynchronousOnlyOperation
[источник] ¶ SynchronousOnlyOperation
Возбуждаются исключение , когда код , который разрешен только в синхронном коде Python вызываются из асинхронного контекста (нить с управлением асинхронным циклом событий). Эти части Django, как правило, сильно зависят от потоковой безопасности для работы и не работают правильно в сопрограммах, использующих один и тот же поток.Если вы пытаетесь вызвать код, который является синхронным только из асинхронного потока, создайте синхронный поток и вызовите его в нем. Вы можете сделать это с помощью
asgiref.sync.sync_to_async()
.
Исключения URL Resolver ¶
Исключения URL Resolver определены в django.urls
.
Resolver404
¶
-
исключение
Resolver404
¶ Resolver404
Возбуждается исключение ,resolve()
если путь передаетсяresolve()
не сопоставляется с точки зрения. Это подклассdjango.http.Http404
.
NoReverseMatch
¶
-
исключение
NoReverseMatch
¶ NoReverseMatch
Возбуждаются исключение ,django.urls
когда соответствующий URL в ваших привязках не может быть определен на основании параметров поставки.
Исключения базы данных ¶
Исключения базы данных можно импортировать из файлов django.db
.
Django обертывает стандартные исключения базы данных, чтобы ваш код Django имел гарантированную общую реализацию этих классов.
-
исключение
Error
¶
-
исключение
InterfaceError
¶
-
исключение
DatabaseError
¶
-
исключение
DataError
¶
-
исключение
OperationalError
¶
-
исключение
IntegrityError
¶
-
исключение
InternalError
¶
-
исключение
ProgrammingError
¶
-
исключение
NotSupportedError
¶
Оболочки Django для исключений базы данных ведут себя точно так же, как и базовые исключения базы данных. ВидетьPEP 249 , Спецификация API базы данных Python v2.0, для получения дополнительной информации.
Согласно 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.contrib.sessions.exceptions
.
SessionInterrupted
¶
-
исключение
SessionInterrupted
[источник] ¶ - Новое в Django 3.2.
SessionInterrupted
возникает, когда сеанс уничтожается в параллельном запросе. Это подклассBadRequest
.
Исключения транзакций ¶
Исключения транзакций определены в django.db.transaction
.
TransactionManagementError
¶
-
исключение
TransactionManagementError
¶ TransactionManagementError
возникает при любых проблемах, связанных с транзакциями базы данных.
Исключения среды тестирования ¶
Исключения, предусмотренные django.test
пакетом.
RedirectCycleError
¶
-
исключение
client.
RedirectCycleError
¶ RedirectCycleError
возникает, когда тестовый клиент обнаруживает цикл или слишком длинную цепочку перенаправлений.
Исключения Python ¶
Django также вызывает встроенные исключения Python, когда это необходимо. См. Документацию Python для получения дополнительной информации о встроенных исключениях .