0

他のエンティティ（クライアントなど）によって生成されたデータを処理する、分離されたPythonコードがあるとします。

私が受け取るデータは間違った形式である可能性があります（たとえば、クライアントのだらしなさ、データの破損、名前を付けるなど）。そのため、Pythonコードでの処理が何らかの理由で失敗し、例外が発生します。ダウンストリームのコードが、処理が正しくて間違っているかどうかを知ることに関心があり、なぜそれが間違っているのかではないと仮定しましょう。

私の懸念は次のとおりです。複雑な不正な入力に対してそのような例外を発生させるためのベストプラクティスは何ですか？この場合の例外を整理するにはどうすればよいですか？

特にデータの正しいフォーマットが複雑な場合、データは多くの点で不正確であることが判明する可能性があります。自分でエラーを簡単にキャッチできる場合もありますが（たとえば、間違ったマジック値を見つけた場合は、を上げることFancyCustomizedExceptionができます）、他の場合には、いくつかの一般的な例外も発生する可能性があります（たとえば、いくつかValueException）。

例外が発生した場合に処理が間違っていたと言っても大丈夫ですか（この場合、ダウンストリームのコードは非常に一般的な（そして醜い）ものを使用しますtry: ... except: ...）？

すべての一般的な例外をキャッチして、それらを私の内部に隠す方が良いですかFancyCustomizedException（この場合、ダウンストリームのコードは非常に一般的ではないものを使用しますが、コードをtry: ... except FancyCustomizedException, e: ...散らかします）？try: ... except: ...

4

3 に答える 3

2

かなりの検証が必要なように思われるので、ValidationSummaryオブジェクト/インスタンス（問題が発生したすべてのリストを含む）の特定の入力ですべての検証「エラー」をラップし、代わりにそれを渡します。

より一般的な注意：他の言語とは異なり、例外処理によるプログラムフローの構造化は一般的であり、Pythonで受け入れられます。これに関連するPythonイディオムはEAFPと呼ばれます（許しを求めてから許可を求める方が簡単です）。

于 2012-04-27T07:26:18.083 に答える
1

IMHOは、独自の例外階層を作成することをお勧めします。たとえば、ValueXExceptionなどの一般的な検証例外の場合はBaseValidationException、カスタム例外などの場合は他の階層など、あらゆる状況で具体的な例外をスローします。必要に応じて、ベースまたは特定の例外で...

ProcessException
  + ValidationException
    + ValueXException
    + LimitYException
  + FancyCustomExceptionA
    + FancyCustomDetailException
  + FancyOtherExtensionB
    ...

常にProcessExceptionでフィルタリングするか、特定の例外をキャッチすることができます...

于 2012-04-27T08:38:14.803 に答える
0

私の意見では、例外を使用する方が、関数からエラーコードを返すよりも信頼性が高くなります。その理由は、戻り値をテストすると、呼び出しの周りのコードが読みにくくなり、チェックしない傾向があるためです。だから、例外のために行きなさい。

よくわからない場合は、一般的な例外のみを使用してください。つまり、独自の例外クラスを作成しないでください。後でいつでも追加できます。多くの新しい例外を作成するよりも、例外がどのような種類（既存の例外）であるかについてもっと考える方がおそらく良いでしょう。

（例外を介して）すべてがうまくいかないことについて文句を言うコアを持つようにコードを書くことができます。次に、より寛容で、いくつかの状況を解決するために賢くしようとするレイヤーを書くことができます。（ただし、ソフトウェアの巧妙さがユーザーを夢中にさせることがあります:)

于 2012-04-27T08:01:58.673 に答える