Django例外

DJango会抛出一些它自己的异常,以及Python的标准异常。

Django核心例外

Django核心异常类定义在django.core.exceptions中。

AppRegistryNotReady

例外 AppRegistryNotReady[source]

当在app loading process(初始化ORM)之前尝试使用模型时,会引发此异常。

ObjectDoesNotExist

例外 ObjectDoesNotExist[source]

The base class for DoesNotExist exceptions; a try/except for ObjectDoesNotExist will catch DoesNotExist exceptions for all models.

ObjectDoesNotExistDoesNotExist的更多信息请见 get()

EmptyResultSet

例外 EmptyResultSet[source]

如果查询不返回任何结果,则在查询生成期间可能会引发EmptyResultSet 大多数Django项目不会遇到此异常,但它可能有助于实现自定义查找和表达式。

在Django更改1.11:

在旧版本中,它只能从django.db.models.sql导入。

FieldDoesNotExist

例外 FieldDoesNotExist[source]

当被请求的字段在模型或模型的父类中不存在时,FieldDoesNotExist异常由模型的 _meta.get_field()方法抛出。

MultipleObjectsReturned

例外 MultipleObjectsReturned[source]

MultipleObjectsReturned异常由查询产生,当预期只有一个对象,但是有多个对象返回的时候。 django.core.exceptions中提供了此异常的基本版本;每个模型类都包含一个子类的版本,可用于标识已返回多个对象的特定对象类型。

详见get()

SuspiciousOperation

例外 SuspiciousOperation[source]

当用户进行的操作在安全方面可疑的时候,抛出SuspiciousOperation异常,例如篡改会话cookie。 SuspiciousOperation的子类包括:

  • DisallowedHost
  • DisallowedModelAdminLookup
  • DisallowedModelAdminToField
  • DisallowedRedirect
  • InvalidSessionKey
  • RequestDataTooBig
  • SuspiciousFileOperation
  • SuspiciousMultipartForm
  • SuspiciousSession
  • TooManyFieldsSent

如果SuspiciousOperation异常到达了WSGI处理器层,它会在Error层记录,并导致HttpResponseBadRequest异常。 详见logging documentation

PermissionDenied

例外 PermissionDenied[source]

PermissionDenied异常当用户不被允许来执行请求的操作时产生。

ViewDoesNotExist

例外 ViewDoesNotExist[source]

当请求的视图不存在时,ViewDoesNotExist异常由django.urls引发。

MiddlewareNotUsed

例外 MiddlewareNotUsed[source]

当中间件没有在服务器配置中出现时,产生MiddlewareNotUsed异常。

ImproperlyConfigured

例外 ImproperlyConfigured[source]

DJango配置不当时产生ImproperlyConfigured异常 -- 例如,settings.py中的值不正确或者不可解析。

FieldError

例外 FieldError[source]

FieldError异常当模型字段上出现问题时产生。 它会由以下原因造成:

  • 模型中的字段与抽象基类中相同名称的字段冲突。
  • 排序造成了一个死循环。
  • 关键词不能由过滤器参数解析。
  • 字段不能由查询参数中的关键词决定。
  • 连接(join)不能在指定对象上使用。
  • 字段名称不可用。
  • 查询包含了无效的 order_by参数。

ValidationError

例外 ValidationError[source]

当表单或模型字段验证失败时抛出ValidationError异常。 关于验证的更多信息,请见Form and Field Validation, Model Field ValidationValidator Reference

NON_FIELD_ERRORS

NON_FIELD_ERRORS T0> ¶ T1>

在表单或者模型中不属于特定字段的ValidationError 被归类为NON_FIELD_ERRORS 此常量用作字典中的键,否则将字段映射到其各自的错误列表。

URL解析器异常

URL解析器异常在django.urls中定义。

自1.10版以来已弃用 在旧版本中,这些异常位于django.core.urlresolvers中。 从旧位置导入将继续工作,直到Django 2.0。

Resolver404

例外 Resolver404[source]

The Resolver404 exception is raised by resolve() if the path passed to resolve() doesn’t map to a view. 它是 django.http.Http404的子类。

NoReverseMatch

例外 NoReverseMatch[source]

当您的URLconf中的匹配URL无法根据提供的参数进行标识时,NoReverseMatch异常将由django.urls引发。

数据库异常

数据库异常由django.db导入。

Django封装了标准的数据库异常,以便确保你的DJango代码拥有这些类的通用实现。

例外 Error[source]
例外 InterfaceError[source]
例外 DatabaseError[source]
例外 DataError[source]
例外 OperationalError[source]
例外 IntegrityError[source]
例外 InternalError[source]
例外 ProgrammingError[source]
例外 NotSupportedError[source]

Django数据库异常的包装器的行为和底层的数据库异常一样。 详见PEP 249,Python 数据库 API 说明 v2.0。

按照 PEP 3134__cause__属性会在原生(底层)的数据库异常中设置,允许访问所提供的任何附加信息。 (请注意,这个属性可以在Python 2和Python 3两者下使用,尽管 PEP 3134通常仅适用于Python 3。 为了避免与Python 3出现意想不到的差异,Django还将确保通过__cause__可用的异常具有可用的__traceback__属性。

在Django更改1.10:

添加了上述的__traceback__属性。

例外 楷模。 ProtectedError T0> ¶ T1>

使用django.db.models.PROTECT时,抛出异常来阻止所引用对象的删除。 models.ProtectedErrorIntegrityError的子类。

Http异常

HTTP异常由django.http导入。

UnreadablePostError

例外 UnreadablePostError[source]

用户取消上传时抛出UnreadablePostError异常。

交易异常

事务异常定义在django.db.transaction中。

TransactionManagementError

例外 TransactionManagementError[source]

对于数据库事务相关的任何问题,抛出TransactionManagementError异常。

测试框架异常

由DJango django.test 包提供的异常。

RedirectCycleError

例外 客户。 RedirectCycleError T0> ¶ T1>

当测试客户端检测到重定向的循环或者过长的链时,抛出RedirectCycleError异常。

Python异常

Django在适当的时候也会抛出Python的内建异常。 进一步的信息请见Built-in Exceptions的Python文档。