私はDjangoで独自のミドルウェアクラスを作成しましたが、これは最近まで問題なく機能していました。奇妙なことに、process_requestは正常に呼び出されますが、応答が500(内部サーバーエラー)の場合でも、process_exceptionはまったく呼び出されません。なんで?
ミドルウェアクラスを、設定ファイルのインストール済みミドルウェアのリストの最初のエントリとして宣言するか、最後のエントリとして宣言するかは関係ありません。
ありがとう、デイブ
私はDjangoで独自のミドルウェアクラスを作成しましたが、これは最近まで問題なく機能していました。奇妙なことに、process_requestは正常に呼び出されますが、応答が500(内部サーバーエラー)の場合でも、process_exceptionはまったく呼び出されません。なんで?
ミドルウェアクラスを、設定ファイルのインストール済みミドルウェアのリストの最初のエントリとして宣言するか、最後のエントリとして宣言するかは関係ありません。
ありがとう、デイブ
process_exception
ビューException
が. コメントで言うように
ビューで例外が発生した
場合は、例外ミドルウェアを介して実行し、例外ミドルウェアが応答を返す場合はそれを使用します。
それ以外の場合は、例外を再発生させます。
構成の誤り、インポート エラーによって発生した例外でprocess_request
あり、キャッチしてハンドラー process_view
にフィードすることはできません。process_exception
動作するかどうかをテストするprocess_exception
には、正常に動作することを確認した後、ビューで例外を発生させます。
process_request
と の間には直接的な関係はありませんprocess_exception
。これらはさまざまな目的のハンドラーであり、さまざまな段階で呼び出されます。正常に実行された後、ビューの前に発生した例外は、前述process_request
のようにキャッチおよび処理されませんprocess_exception
。
ドキュメントによると、process_exception、
process_exception(self, request, exception)
HttpRequest オブジェクト、view 関数によって発生した Exception オブジェクトを引数として受け取り、応答として HttpResponse オブジェクトを返します。そのため、コードが 500 エラー (HttpResponse オブジェクト) を発生させた場合は呼び出されません。process_exception は、キャッチされていない場合にのみ呼び出されます。ビューの例外。