Django は普通の Python の例外の他に、いくつか独自の例外も起こします。
Django core 例外クラスは django.core.exceptions で定義されています。
AppRegistryNotReady¶この例外は、ORM を初期化する アプリケーション読み込みプロセス が完了する前にモデルを使用しようとしたときに発生します。
ObjectDoesNotExist¶Model.DoesNotExist 例外の基底クラスです。ObjectDoesNotExist のための try/except は、すべてのモデルの DoesNotExist 例外をキャッチします。
get() を参照してください。
EmptyResultSet¶FullResultSet¶FieldDoesNotExist¶MultipleObjectsReturned¶Model.MultipleObjectsReturned 例外の基底クラスです。MultipleObjectsReturned の try/except は、すべてのモデルの MultipleObjectsReturned 例外をキャッチします。
get() を参照してください。
SuspiciousOperation¶SuspiciousOperation 例外は、セッションクッキーの改ざんなど、セキュリティの観点から疑わしいとみなされる操作をユーザーが行った場合に発生します。 SuspiciousOperation のサブクラスには以下が含まれます:
DisallowedHost
DisallowedModelAdminLookup
DisallowedModelAdminToField
DisallowedRedirect
InvalidSessionKey
RequestDataTooBig
SuspiciousFileOperation
SuspiciousMultipartForm
SuspiciousSession
TooManyFieldsSent
TooManyFilesSent
もし SuspiciousOperation 例外が ASGI/WSGI ハンドラレベルに達した場合、Error レベルでログ記録され、 HttpResponseBadRequest が結果として返されます。 詳細については、ロギングのドキュメント を参照してください。
PermissionDenied¶PermissionDenied 例外は、ユーザーにリクエストされたアクションを実行する権限がない場合に発生します。
ViewDoesNotExist¶ViewDoesNotExist 例外は、リクエストされたビューが存在しないい場合に、django.urls によって発生します。
MiddlewareNotUsed¶MiddlewareNotUsed 例外は、サーバーの設定の中でミドルウェアが使用されなかった時に発生します。
ImproperlyConfigured¶ImproperlyConfigured 例外は、Django が何らかの点で不適切に設定されている場合に発生します。たとえば、settings.py に含まれる値が不正であったり、パースできないような場合が考えられます。
FieldError¶FieldError 例外は、モデルのフィールドに問題がある時に発生します。発生理由としては、次のようないくつかの理由が考えられます。
モデル内のフィールドが、抽象基底クラスからの同名のフィールドと衝突しています
ソートによって無限ループが起こります
フィルタパラメータからキーワードを解析できません
クエリパラメータのキーワードからは、フィールドを特定できません
指定されたフィールドに対する結合は許可されていません
フィールド名が無効です
クエリに無効な order_by 引数が含まれています
ValidationError¶ValidationError 例外は、データがフォームまたはモデルのフィールド検証に失敗すると発生します。検証 (validation) のより詳しい情報については、フォームとフィールドのバリデーション や モデルフィールドのバリデーション、バリデータのリファレンス を参照してください。
NON_FIELD_ERRORS¶ValidationError でフォームやモデルの特定のフィールドに属さないものは、 NON_FIELD_ERRORS として分類されます。この定数は、他のフィールドをそれぞれのエラーリストにマッピングする辞書でキーとして使用されます。
BadRequest¶BadRequest 例外は、クライアントエラーによりリクエストを処理できない場合に発生します。 BadRequest 例外が ASGI/WSGI ハンドラレベルに到達すると、 HttpResponseBadRequest が結果として返されます。
RequestAborted¶RequestAborted 例外は、ハンドラによって読み込まれた HTTP ボディが途中で切断され、クライアント接続が閉じられるか、またはクライアントがデータを送信せず、サーバーが接続を閉じるタイムアウトに達したときに発生します。
これはHTTPハンドラーモジュール内部のもので、他の場所で見ることはまずありません。HTTP処理コードを変更している場合、ソケットがクリーンに閉じられるように、中断されたリクエストに遭遇した際にはこれを発生させるべきです。
SynchronousOnlyOperation¶SynchronousOnlyOperation 例外は、同期的な Python コードでのみ許可されているコードが、実行中の非同期イベントループを持つスレッドから非同期コンテキストで呼び出されたときに発生します。Django のこれらの部分は、一般に機能するためにスレッドセーフに大きく依存しており、同じスレッドを共有するコルーチンの下では正しく動作しません。
非同期スレッドから同期専用のコードを呼び出そうとしている場合は、同期スレッドを作成し、その中で呼び出してください。これは、 asgiref.sync.sync_to_async() を使用して実現できます。
URL Resolver の例外は django.urls で定義されています。
Resolver404¶Resolver404 例外は、resolve() に渡されたパスがビューにマッピングされていない場合に、 resolve() によって発生します。これは django.http.Http404 のサブクラスです。
NoReverseMatch¶NoReverseMatch 例外は、提供されたパラメータに基づいてURLconf内の一致するURLを特定できない場合に、 django.urls によって発生します。
データベースの例外は django.db からインポートできます。
Django は標準のデータベース例外をラップしており、これによって Django コードにはこれらのクラスの共通の実装が保証されます。
Djangoのデータベース例外のラッパーは、基になるデータベース例外と全く同じ動作をします。詳細については、 PEP 249 、Python Database API Specification v2.0 を参照してください。
PEP 3134 に従って、 __cause__ 属性が、追加情報へのアクセスを可能にする元の(ベースとなる)データベース例外とともに設定されます。
参照されているオブジェクトの削除を防ぐために発生させられる django.db.models.PROTECT を使用しています。 models.ProtectedError は IntegrityError のサブクラスです。
django.db.models.RESTRICT を使用して参照されているオブジェクトの削除を防ぐために発生します。 models.RestrictedError は IntegrityError のサブクラスです。
HTTPの例外は django.http からインポートできます。
UnreadablePostError¶UnreadablePostError は、ユーザーがアップロードをキャンセルすると発生します。
セッションの例外は django.contrib.sessions.exceptions で定義されています。
SessionInterrupted¶SessionInterrupted は、並行リクエストでセッションが破棄された場合に発生します。これは BadRequest のサブクラスです。
トランザクションの例外は django.db.transaction で定義されています。
TransactionManagementError¶TransactionManagementError が発生するのは、データベースのトランザクションに関するあらゆる問題に対してです。
django.test パッケージが提供する例外です。
RedirectCycleError¶RedirectCycleError は、テストクライアントがループまたは過度に長いリダイレクトの連結を検出した時に発生します。
Django は、十分適切な場合にはビルトインの Python の例外を起こします。詳しい情報については、Python のドキュメント Built-in Exceptions を読んでください。
4月 02, 2025