ASP.NET MVC 4、HttpExceptionとHttpStatusCodeResultを返します。

Question

RESTfulサービスを開発中です。サポートされていないすべてのURLについて400を返したいと思います。

私の質問は、この1つは、より良いように思わ

//method 1 
public ActionResult Index() 
{ 
    //The url is unsupported 
    throw new HttpException(400, "Bad Request"); 
} 

..私は方法2およびその逆の上に方法1を選択する必要がある場合 のですか？

//method 2 
public ActionResult Index() 
{ 
    //The url is unsupported 
    return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request"); 
} 

Answer 1

第2の例は、第1の例と比較してマイクロコストになる例外投げを伴わないので、より良好と思われる。

Answer 2

私の見解では、サポートされていないURLが要求された場合は、最初に検討する必要があります。あなたはそれが例外的な状況だと思いますか、それが起こることを期待していますか？例外的な状況だと思う場合は、例外を作成してスローします（オプション1）。サポートされていないURLで多くのリクエストを受け取ることを期待している場合は、アプリケーションの関数として扱い、メソッド2を使用します。

これは、あまりにも多くを期待している場合は、サポートされていないURLのリクエスト。私はサポートされていないURLに対してあまりにも多くのリクエストを受け取ることを期待していないので、一般的に私は例外をスローすることを好むでしょう、そして、それが起こった場合、私はそれを例外としてログに記録し、

Answer 3

DevOpsチームに所属している私たちは、多少のハードウェアを投げ込んでいくと少し良い結果が得られるという心がけにあります。ですから、私は意図的に.NET例外を発生させるためのマイクロコストを無視しています。

ApplicationInsightsのような遠隔測定フレームワークを利用している場合、ステータスコードを返すだけでは、「失敗した要求」以上のものはありません。失敗したリクエストの「理由」に関する情報をコンパイルまたは取得するための有用な情報はありません。

遠隔測定プラットフォームでは、エラーのテレメトリーは通常.NET例外の周りにあるため、投げたいと思うので、投げていないと操作に問題が発生しています。

私は人々がtry{} catch { return BadRequest("put_the_reason_here"); }を書くことを愛し、どちらもDevOpsチームやDevのチームはApplicationInsightsのシステムテレメトリに便利な何も見えないプロジェクトのためRoslynアナライザとCodeFixを書き込む処理にいるので、私は実際に、ここに上陸しました。

Answer 4

この質問は少し古いですが、私はこれを見つけたので私は私の入力を与えると思いました。

エラーは値です。これはHttpException（未投函の場合）とHttpStatusCodeResultになります。ただし、例外がスローされると、あなたの同僚よりも隠れている新しいコードパスが作成されます。このコードパスは、あなたよりも実行コンテキストが高い場合があり、これらのコードパスが通知なしに渡されることを示すドキュメントが必要です。しかし、値は、あなたがそのタイプを通して知る必要があるすべてを教えてくれます。エラーが発生したかどうか、またそのエラーに関する関連情報を見つけてログに記録するために、予想される実行パスでそのタイプを使用できます。

デビッド・ロドリゲスが言及した有用なデバッグ情報を抽出するために、次の実行コンテキストに投げずに（軽く拡張された）Exceptionを使用することがあります。実際には例外ではない実行コンテキストに例外を渡すことは決してできません。これはコードの処理能力（StackOverflowException、その他の致命的なシステム例外など）に実際には当てはまりません。

実行しているMVCサービスなどのネットワークアプリケーションでは、例外をスローすることによるパフォーマンスの低下は無意味です。セマンティクスと保守性への影響はそうではありません。

ネットワークエラーは値であり、そのように扱う必要があります。