許可ではなく許しを求めてください: 例外処理がプリエンプティブ チェックよりも優れているのはどのような場合ですか?

「許可ではなく許しを求める」: 技術的な説明

プログラミングでは、「許可ではなく許しを求める」というフレーズは 2 つの対照的なコーディング スタイルを表します。 :

「許可を求める」スタイル:

if can_do_operation():
    perform_operation()
else:
    handle_error_case()

「許しを求める」 スタイル:

try:
    perform_operation()
except Unable_to_perform:
    handle_error_case()

「許可を求める」アプローチでは、can_do_operation の存在() チェックにより、操作を実行できない場合は、perform_operation() 呼び出しが実行されなくなります。ただし、このアプローチは can_do_operation() チェックの精度に依存しているため、動的環境や外部リソースを扱う場合には必ずしも信頼できるとは限りません。

「許しを求める」の利点

「許しを乞う」スタイルでは、いくつかのオプションが提供されます。利点:

• 同時状況の処理: マルチスレッド環境またはマルチリソース環境では、チェックと操作の間で条件が変化する可能性があり、「許可を求める」アプローチが効果的でなくなります。
• 過度に制限的なチェックを回避します: 「許可を求める」には必要があります正確かつ包括的な基準を定義することは困難であり、間違いが発生しやすい可能性があります。 「許しを求める」アプローチにより、柔軟性が高まり、有効な操作が意図せずに除外されることがなくなります。

例: インスタンス属性アクセス

この例では、インスタンス属性にアクセスするときの「許しを求める」の使用について問い合わせたとします。通常はプログラマ エラーとみなされますが、オプションのオブジェクト部分を扱う場合など、存在しない属性へのアクセスは有効なシナリオになる可能性があります。

属性 (foo.bar) の存在をテストする代わりに、例外ハンドラーでは、属性が None でないかどうかを確認するほうが Python 的です。オプションの属性の場合、bar 属性は通常、最初は None に初期化され、使用可能な場合は意味のある値に設定されます。これにより、次のテストが可能になります。

if foo.bar is not None:
    handle_optional_part(foo.bar)
else:
    default_handling()

結論

「許可ではなく許しを求める」原則は、特に次の場合に、プログラム実行の自然な部分として例外を受け入れることを推奨します。オプションの機能または外部リソースの対話を処理します。これにより、動的環境および同時環境での柔軟性と適応性が向上し、同時に例外処理メカニズムによるエラー処理も可能になります。

以上が許可ではなく許しを求めてください: 例外処理がプリエンプティブ チェックよりも優れているのはどのような場合ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。