NotImplementedExceptionの使用

NotImplementedExceptionあなたがまだ書いていないコードを投げることは悪い習慣と考えられていますか？おそらくTODOコメントはより安全だと考えられますか？

NotImplementedException実際には良い習慣だと思います。

実際、メソッドを実装するのを忘れて、プロジェクトで後でそれを使用する場合（そして、私はそれが起こると信じています）、ステップごとに間違ったものを探すためにデバッグに長い時間を費やすかもしれません。例外がある場合、プログラムは直接停止し、例外を促します（例外をキャッチした場合は、キャッチした例外を調べることですぐに見つけられます）。

GUIヘルプ（VSのタスク）とプログラムの安全性を組み合わせるために、TODOコメントNotImplementedException と組み合わせて使用することをお勧めします。

ほとんどの場合、プログラムは正常に動作しているが誤った結果を生成するのではなく、プログラムをクラッシュさせることを好むため、リリースバージョンの場合、それはさらに重要です。

エラーとエラー処理に関する一般的な考え方に依存します。私は「ハードエラー」タイプの男です。何かが間違っているかもしれないというわずかなヒントで例外をスローします。すべてを主張します。エラーがある場合、何かがそこにあると予想されていて、ない場合、または何かがあり、そうでない場合、宇宙全体を停止する必要があります。窓の感嘆符の音は、スピーカーを通して不吉に鳴らなければなりません。

エラーに煩わされたくない人もいます。それをクライアントに出荷し、コーディングを忘れたためにレポートモジュール全体が欠落し、アプリケーションがそれについてあまりにも沈黙しているためにテストの誰もそれを認識しなかった場合はどうでしょうか。クライアントの顔に例外をスローするよりも、何もしない方が良いです！

いいアイデアだと思います。通常、フォームやダイアグラムなどから自動生成されるスケルトンコードによってスローされる例外を確認します。例外は、コードを実装することを思い出させ、セットアップされたが完全には実装されなかった機能を使用しようとするとエラーが発生することを確認します。ときどきスタブを作成したり、実行を停止する可能性が低いもの（コンソールに警告を出力するなど）に置き換えたりしますが、私にとってはうまくいくことがわかります。

他の人が使用するライブラリを構築している場合、この例外は他の選択肢よりも優れています。ライブラリのユーザーが関数を呼び出して、何も起こらないように思えるのです。もちろん、出荷されたライブラリでこの例外を持つことはまだかなり悪いですが、サイレント障害、IMOよりも優れています。

良い習慣だと思います。別の方法は、無効な値または状態を伝播することです。これは、テストコードと実稼働コードの両方に影響を与えます。

私は常に使用していますNotImplementedException-結局のところ、それが目的です。

これは、「フェールファースト」の概念に関連しています。コードが例外をスローしている場合、実稼働に移行する前に例外をキャッチする必要があります。本番環境に到達した場合、少なくともクライアントはアセンブリが正しくないことを知っています。

コードが無意味な値を返す場合、またはvoidメソッドの場合はアクションを実行しない場合、コードのコンシューマーは、呼び出しが意味のないときに意味があると合理的に考えるかもしれません。その後、正しいコードを取得すると、前の不正な動作に依存するため、コードが破損する可能性があります。

これはどのようなプロジェクトですか？仕事か家庭か 自宅では、あなたがやりたいことを何でもします-あなたが取り組んでいるものは何でも終了する必要があることを最もよく思い出させます。

仕事で、それを書き終えます。

私は、他の開発者、QA、またはビルドを壊す可能性がある/壊すコードをチェックインする状況を見ることができません。

私は私のdoxygene autodocingで\ todo以外の両方を実行し、例外をスローします。そうすれば、人々が少なくともRTFMに煩わされなければ、論理値を返さない宣言された関数があるのではなく、プログラムがクラッシュした理由を理解することができます。