DJango会抛出一些它自己的异常，以及Python的标准异常。
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.
ObjectDoesNotExist 和 DoesNotExist的更多信息请见 get()。
EmptyResultSet¶FieldDoesNotExist¶MultipleObjectsReturned¶MultipleObjectsReturned[source]¶MultipleObjectsReturned异常由查询产生，当预期只有一个对象，但是有多个对象返回的时候。 django.core.exceptions中提供了此异常的基本版本；每个模型类都包含一个子类的版本，可用于标识已返回多个对象的特定对象类型。
详见get()。
SuspiciousOperation¶SuspiciousOperation[source]¶当用户进行的操作在安全方面可疑的时候，抛出SuspiciousOperation异常，例如篡改会话cookie。 SuspiciousOperation的子类包括：
DisallowedHostDisallowedModelAdminLookupDisallowedModelAdminToFieldDisallowedRedirectInvalidSessionKeyRequestDataTooBigSuspiciousFileOperationSuspiciousMultipartFormSuspiciousSessionTooManyFieldsSent如果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异常当模型字段上出现问题时产生。 它会由以下原因造成：
ValidationError¶ValidationError[source]¶当表单或模型字段验证失败时抛出ValidationError异常。 关于验证的更多信息，请见Form and Field Validation, Model Field Validation 和 Validator Reference。
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代码拥有这些类的通用实现。
Django数据库异常的包装器的行为和底层的数据库异常一样。 详见PEP 249，Python 数据库 API 说明 v2.0。
按照 PEP 3134，__cause__属性会在原生（底层）的数据库异常中设置，允许访问所提供的任何附加信息。 （请注意，这个属性可以在Python 2和Python 3两者下使用，尽管 PEP 3134通常仅适用于Python 3。 为了避免与Python 3出现意想不到的差异，Django还将确保通过__cause__可用的异常具有可用的__traceback__属性。
添加了上述的__traceback__属性。
楷模。 ProtectedError T0> ¶ T1>使用django.db.models.PROTECT时，抛出异常来阻止所引用对象的删除。 models.ProtectedError是IntegrityError的子类。
HTTP异常由django.http导入。
UnreadablePostError¶UnreadablePostError[source]¶用户取消上传时抛出UnreadablePostError异常。
事务异常定义在django.db.transaction中。
TransactionManagementError¶TransactionManagementError[source]¶对于数据库事务相关的任何问题，抛出TransactionManagementError异常。
由DJango django.test 包提供的异常。
RedirectCycleError¶客户。 RedirectCycleError T0> ¶ T1>当测试客户端检测到重定向的循环或者过长的链时，抛出RedirectCycleError异常。
Django在适当的时候也会抛出Python的内建异常。 进一步的信息请见Built-in Exceptions的Python文档。
2017年9月6日