8

特定の例外タイプをキャッチし、例外のメッセージを調べて、それが実際にキャッチしたい例外であるかどうかを確認し、そうでない場合は例外を再発生させる状況があります。

try:
    # do something exception-prone
except FooException as e:
    if e.message == 'Something I want to handle':
        # handle the exception
    else:
        raise e

これは問題なく動作しますが、問題が 1 つあります。raise e例外を再発生させた場合、その例外は、例外が最初に発生した場所ではなく、再発生させた行 (つまり) で発生します。これは、元の例外がどこで発生したかを知りたいデバッグには理想的ではありません。

したがって、私の質問: 元の例外の場所を維持しながら、例外をキャッチした後、例外を再発生させるか、「渡す」方法はありますか?

注: 実際の状況がどうなっているのか疑問に思っている場合: を使用していくつかのモジュールを動的にインポートしています__import__ImportErrorこれらのモジュールのいずれも存在しない場合を適切に処理するためにキャッチしています。ただし、これらのモジュール自体に を発生させる import ステートメントが含まれている場合は、ImportErrorそれらの「実際の」(アプリケーションの観点から) 例外を発生させ、デバッグ ツールに関する限り元の場所で発生させたいと考えています。心配です。

4

1 に答える 1

10

ただ行う:

raise

の代わりにraise e例外の発生に関するチュートリアルセクション、およびステートメントの言語リファレンスraiseも参照してください。

式が存在しない場合、raiseは、現在のスコープでアクティブだった最後の例外を再発生させます。現在のスコープでアクティブな例外がない場合は、これがエラーであることを示すTypeError例外が発生します(IDLEで実行している場合は、代わりにQueue.Empty例外が発生します)。

于 2012-08-31T05:41:11.803 に答える