3

私は GAE を 1 年以上使用していますが、対処するのが最も難しいことの 1 つは、他の方法では適切に作成されたコードが、GAE の問題のために例外を発生させることがあるという事実です。

未処理の例外に対する適切な手順が既にあります。私のカスタム リクエスト ハンドラは適切なエラー ページを表示し、管理者は電子メールを受け取ります。ただし、これは悪いユーザー エクスペリエンスです。

私がやりたいことは、例外を処理することです。これにより、すぐに適切なアクションを実行して、一般的なエラー ページを防ぐことができます。

私の質問は次のとおりです。

  1. どの例外をキャッチする必要がありますか?
  2. どこで捕まえればいいですか？

これに対する完全な答えは実用的ではないことを認識していますが、最も一般的な状況でのベスト プラクティスをいくつか探しています。

キャッチする必要がある例外については、公式リストにない例外を時々見かけます。たとえば、UnknownError を受け取りました。

例外をキャッチする場所については、get/post メソッドごとにキャッチする必要があるのでしょうか。このようなもの：

def get(self):
    try:
        # normal get processing
    except SomeException:
        # redirect to the same page to try again and fix any data if necessary

これはGAEアプリの重要な側面であるため、これに関する情報が他にないことに驚いています。こことここにいくつかの良い記事がありますが、これらは私の質問に答えません.

4

1 に答える 1

0

どの例外をキャッチする必要がありますか?

それは、あなたがしようとしているエラーキャッチのレベルに依存します。私の経験から、公式リストとリンクされた記事でエラーをキャッチすると、非常に高いレベルのエラー キャッチが得られます。それ以上のことが必要な場合は、未知のエラーを予測しようとするよりもジェネリックを除外する方が簡単です。

どこで捕まえればいいですか？

GAE エラーが発生する可能性が最も高いのは、データベースと対話するときです。そのため、そうでない場合はそこにいくつかの try-except ブロックを設定すると、GAE の問題のエラー処理に対処するための努力に対して良い見返りが得られます。

リンクされた記事のアドバイスに加えて、失敗した操作をタスク キューに入れることも考えられます。各タスクは、失敗する前に自動的に 5 回再試行されます。これにより、操作からの即時のフィードバックが必要ない場合に、データストアの切り替えやその他のサービスの中断を乗り切ることができます。

于 2012-07-03T23:53:12.287 に答える