1

関数が失敗するのが正常な場合、たとえば、データベースでレコードが見つからない場合や、値が存在しない可能性があることを示すその他の状況が発生した場合、このケースを処理するために例外を使用することをお勧めしますか?

疑似コードの例:

function retrieve(foo):
  results = db.query("SELECT * FROM bar WHERE foo="+foo)
  if not results:
    throw Exception("no results")
  return results[0]

function main:
  try:
    record = retrieve(42)
  except:
    print "no record with 42"
    .... will create the record and continue
  else:
    print "record found: "+record
    .... will use the existing record and continue

別の解決策として、この例外を起動する代わりに null 値を返すことがあります。アンチパターンである可能性が最も高いのはどれですか? 例外を使用する方が適切な場合とそうでない場合はどれですか?

4

3 に答える 3

3

Joshua Bloch は「Effective Java」で次のように要約しています。

例外は、その名前が示すように、例外的な条件にのみ使用されます。通常の制御フローには使用しないでください

この書籍の対応するスニペット (「項目 57: 例外的な条件にのみ例外を使用する」) は、Google ブックスで見つけることができます。

例外の乱用が理解しにくいコードにつながる可能性があるという理由に加えて、ブロッホには、今日の JVM 実装に有効な理由があります。

例外は例外的な状況向けに設計されているため、JVM の実装者が明示的なテストと同じくらい高速にするインセンティブはほとんどありません。

(ホットスポット) JVM の場合、例外を作成するのはかなりコストがかかります (生成されたスタックトレースを考えてみてください)。

于 2013-08-26T08:20:04.663 に答える
1

.Net Framework Development Guidelinesから:

可能であれば、通常の制御フローに例外を使用しないでください。

システム障害や潜在的な競合状態を伴う操作を除き、フレームワークの設計者は、ユーザーが例外をスローしないコードを記述できるように API を設計する必要があります。たとえば、ユーザーが例外をスローしないコードを記述できるように、メンバーを呼び出す前に前提条件を確認する方法を提供できます。

別のメンバーの前提条件をチェックするために使用されるメンバーはしばしばテスターと呼ばれ、実際に作業を行うメンバーは実行者と呼ばれます。

Tester-Doer パターンのパフォーマンス オーバーヘッドが許容できない場合があります。このような場合、いわゆる Try-Parse パターンを考慮する必要があります (詳細については、例外とパフォーマンスを参照してください)。

于 2013-08-23T10:53:02.190 に答える
0

一般に、例外を使用するとオーバーヘッドが高くなり、それらを悪用するとアプリケーションの速度が低下する可能性があります。クエリでレコードが見つからないことは例外ではないので、null を返すことをお勧めします。

いいえ、通常の制御フローに例外を使用することはお勧めできません。

于 2013-08-23T09:06:49.740 に答える