.net - NotImplementedException が存在するのはなぜですか?

Question

これは本当に、本当に私を悩ませているので、誰かがなぜ物事がそのままであるかについて合理的な正当化をしてくれることを願っています.

NotImplementedException. あなたは私の足を引っ張っていますよね？

いいえ、「ちょっと待ってください。メソッドが実装されているので、NotImplementedException がスローされます」と安易に言うつもりはありません。はい、そうです。NotImplementedException をスローするメソッドを実装する必要があります (C++ での純粋な仮想関数呼び出しとは異なります。これは理にかなっています!)。それはかなりおかしな話ですが、私の心にはもっと深刻な問題があります。

NotImplementedException が存在する場合、どうすれば .Net で何かできるのでしょうか? 実装されていない可能性のあるメソッドから保護するために、すべての抽象メソッド呼び出しを try catch ブロックでラップする必要がありますか? そのような例外をキャッチした場合、一体どうすればよいのでしょうか??

メソッドを呼び出さずに実際に実装されているかどうかをテストする方法がわかりません。それを呼び出すと副作用が生じる可能性があるため、事前にすべてのチェックを行ってからアルゴリズムを実行することはできません。アルゴリズムを実行し、NotImplementedExceptions をキャッチして、アプリケーションを正常な状態にロールバックする必要があります。

それはクレイジーです。狂った。非常識。問題は 、なぜ NotImplementedException が存在するのかということです。

先制攻撃として、「設計者はこれを自動生成コードに入れる必要があるため」と答えてほしくありません。これは恐ろしいです。実装を提供するまで、自動生成されたコードをコンパイルしないでください。たとえば、自動生成された実装は「throw NotImplementedException;」のようになります。NotImplementedException は定義されていません。

NotImplementedException をキャッチして処理したことのある人はいますか? コードに NotImplementedException を残したことがありますか? もしそうなら、これは時限爆弾 (つまり、誤ってそこに置き忘れた) または設計上の欠陥 (メソッドは実装されるべきではなく、決して呼び出されない) を表していますか?

NotSupportedException も非常に疑わしいです... サポートされていませんか? 何？サポートされていない場合、それがインターフェイスの一部になっているのはなぜですか? マイクロソフトの誰かが不適切な継承を綴ることができますか? しかし、この質問に対してあまり虐待を受けなければ、別の質問を始めるかもしれません.

追加情報：

これは、この主題に関する興味深い読み物です。

「NotImplementedException は、まだ実装されていないが、実際には実装されるべき (そして実装される予定) の機能のためのものである」という Brad Abrams との強い合意があるようです。そこに NotImplementedException をスローし、実際のコードでそれらをフラッシュします…」

Jared Parsonsからのコメントは非常に脆弱であり、おそらく無視する必要があります: NotImplementedException: 型が何らかの理由でメソッドを実装しない場合、この例外をスローします。

MSDNはこの件に関してさらに弱く、「要求されたメソッドまたは操作が実装されていない場合にスローされる例外」とだけ述べています。

score 142 · Accepted Answer

役立つと思う状況が 1 つあります。TDD です。

テストを書いてから、テストがコンパイルされるようにスタブを作成します。それらのスタブは何もしませんthrow new NotImplementedException();。この方法では、テストはデフォルトで失敗します。ダミーの戻り値を使用すると、誤検知が発生する可能性があります。実装がないためにすべてのテストがコンパイルされて失敗するようになったので、これらのスタブに取り組みます。

私はNotImplementedException他の状況でa を使用したことがないのでNotImplementedException、リリースコードに no を渡すことは決してありません。

あちらこちらでキャッチする必要はありません。優れた API は、スローされた例外を文書化します。それらはあなたが探すべきものです。

編集: それらを見つけるために FxCop ルールを書きました。

これはコードです：

using System;
using Microsoft.FxCop.Sdk;

/// <summary>
/// An FxCop rule to ensure no <see cref="NotImplementedException"/> is
/// left behind on production code.
/// </summary>
internal class DoNotRaiseNotImplementedException : BaseIntrospectionRule
{
    private TypeNode _notImplementedException;
    private Member _currentMember;

    public DoNotRaiseNotImplementedException()
        : base("DoNotRaiseNotImplementedException",
               // The following string must be the assembly name (here
               // Bevonn.CodeAnalysis) followed by a dot and then the
               // metadata file name without the xml extension (here
               // DesignRules). See the note at the end for more details.
               "Bevonn.CodeAnalysis.DesignRules",
               typeof (DoNotRaiseNotImplementedException).Assembly) { }

    public override void BeforeAnalysis()
    {
        base.BeforeAnalysis();
        _notImplementedException = FrameworkAssemblies.Mscorlib.GetType(
            Identifier.For("System"),
            Identifier.For("NotImplementedException"));
    }

    public override ProblemCollection Check(Member member)
    {
        var method = member as Method;
        if (method != null)
        {
            _currentMember = member;
            VisitStatements(method.Body.Statements);
        }
        return Problems;
    }

    public override void VisitThrow(ThrowNode throwInstruction)
    {
        if (throwInstruction.Expression != null &&
            throwInstruction.Expression.Type.IsAssignableTo(_notImplementedException))
        {
            var problem = new Problem(
                GetResolution(),
                throwInstruction.SourceContext,
                _currentMember.Name.Name);
            Problems.Add(problem);
        }
    }
}

そして、これはルールのメタデータです:

<?xml version="1.0" encoding="utf-8" ?>
<Rules FriendlyName="Bevonn Design Rules">
  <Rule TypeName="DoNotRaiseNotImplementedException" Category="Bevonn.Design" CheckId="BCA0001">
    <Name>Do not raise NotImplementedException</Name>
    <Description>NotImplementedException should not be used in production code.</Description>
    <Url>http://stackoverflow.com/questions/410719/notimplementedexception-are-they-kidding-me</Url>
    <Resolution>Implement the method or property accessor.</Resolution>
    <MessageLevel Certainty="100">CriticalError</MessageLevel>
    <Email></Email>
    <FixCategories>NonBreaking</FixCategories>
    <Owner></Owner>
  </Rule>
</Rules>

これを構築するには、次のことが必要です。

参照Microsoft.FxCop.Sdk.dllとMicrosoft.Cci.dll
という名前のファイルにメタデータを配置し、DesignRules.xmlそれを埋め込みリソースとしてアセンブリに追加します。
アセンブリに名前を付けますBevonn.CodeAnalysis。メタデータまたはアセンブリファイルのいずれかに別の名前を使用する場合は、2 番目のパラメーターを基本コンストラクターに適宜変更してください。

次に、結果のアセンブリを FxCop ルールに追加するだけで、貴重なコードからそれらの忌まわしい例外を取り除くことができます。NotImplementedException がスローされたときにそれが報告されないまれなケースがいくつかありますが、実際にそのようなクトゥルフのコードを書いている場合は絶望的だと思います。通常の使用では、つまりthrow new NotImplementedException();、動作し、それだけが重要です。

score 40 · Accepted Answer

これは、かなり一般的なユースケース、機能しているが部分的にしか完成していない API をサポートするためにあります。開発者に私の API をテストして評価してもらいたいとしWashDishes()ましょDryDishes()うPutAwayDishes()。黙って失敗したり、不可解なエラーメッセージを表示したりするのではなく、なぜ機能しないのかを明確に説明できますDryDishes()。まだ実装していません。

その姉妹例外NotSupportedExceptionは、主にプロバイダーモデルで意味があります。多くの食器洗い機には乾燥機能があるため、インターフェイスに属していますが、割引価格の食器洗い機はそれをサポートしていません。私はそれを介して知らせることができますNotSupportedException

score 28 · Accepted Answer

これに関する私の意見は、いくつかのコメントに散らばっているので、1 か所に要約します。

NotImplementedExceptionインターフェイスメンバーがまだ実装されていないが、実装されることを示すために使用します。これを自動化された単体テストまたは QA テストと組み合わせて、まだ実装する必要がある機能を特定します。
機能が実装されたら、NotImplementedException. 機能が適切に機能することを確認するために、新しい単体テストが作成されます。
NotSupportedException一般に、特定のタイプでは意味をなさない機能をサポートしていないプロバイダーに使用されます。そのような場合、特定の型が例外をスローし、クライアントはそれらをキャッチして適切に処理します。
NotImplementedExceptionフレームワークにとの両方が存在する理由NotSupportedExceptionは単純です。それらにつながる状況は一般的であるため、開発者がそれらを再定義し続ける必要がないように、フレームワークでそれらを定義することは理にかなっています。また、クライアントがキャッチする例外を簡単に知ることができます (特に単体テストのコンテキストで)。独自の例外を定義する必要がある場合は、どの例外をキャッチする必要があるかを把握する必要があります。これは、少なくとも非生産的な時間の浪費であり、多くの場合正しくありません。

score 19 · Accepted Answer

NotImplementedException が存在するのはなぜですか?

NotImplementedException は、何かがまだ準備ができていないことを示す優れた方法です。なぜ準備ができていないのかは、メソッドの作成者にとって別の問題です。実稼働コードでは、この例外をキャッチすることはほとんどありませんが、キャッチした場合は、何が起こったのかをすぐに確認でき、メソッドが呼び出されたのに何も起こらなかった理由を突き止めようとするよりもはるかに優れています。さらに悪いことに、「一時的な」結果を受け取り、「面白い」副作用。

NotImplementedException は Java の UnsupportedOperationException に相当する C# ですか?

いいえ、.NET には NotSupportedException があります

アルゴリズムを実行し、NotImplementedExceptions をキャッチし、いくつかの方法でアプリケーションを正常な状態にロールバックする必要があります

Good API には、考えられる例外を説明する XML メソッドのドキュメントがあります。

NotSupportedException も非常に疑わしいです... サポートされていませんか? 何？サポートされていない場合、それがインターフェイスの一部になっているのはなぜですか?

何百万もの理由が考えられます。たとえば、API の新しいバージョンを導入できますが、古いメソッドをサポートしたくない/サポートできません。繰り返しになりますが、ドキュメントを掘り下げたり、サードパーティのコードをデバッグしたりするよりも、説明的な例外を確認する方がはるかに優れています。

score 12 · Accepted Answer

NotImplementedException 例外の主な用途は、生成されたスタブコードです。そうすれば、実装を忘れることはありません!! たとえば、Visual Studio は、本体が NotImplementedException をスローするインターフェイスのメソッド/プロパティを明示的に実装します。

score 8 · Accepted Answer

Re NotImplementedException- これはいくつかの用途に役立ちます。(たとえば、単体テストが不完全な作業のためにロックできる単一の例外を提供します)。しかし、それは実際に言われていることを実行します: これは (まだ) ありません。たとえば、"mono" は、MS ライブラリに存在するが、まだ作成されていないメソッドに対して、あらゆる場所でこれをスローします。

Re NotSupportedException- すべてが利用できるわけではありません。たとえば、多くのインターフェイスは「これはできますか?」というペアをサポートしています。/ "これを行う"。「これはできますか？」が false を返す場合、「これを行う」がをスローするのは完全に合理的ですNotSupportedException。例はIBindingList.SupportsSearching/IBindingList.Find()などです。

score 6 · Accepted Answer

Microsoft のほとんどの開発者は、NotImplementedException が適切な設計パターンに精通しています。実際にはかなり一般的です。

良い例は複合パターンで、多くのオブジェクトをオブジェクトの 1 つのインスタンスとして扱うことができます。コンポーネントは、(適切に) 継承されたリーフクラスの基本抽象クラスとして使用されます。たとえば、ファイルクラスとディレクトリクラスは、タイプが非常に似ているため、同じ抽象基本クラスから継承される場合があります。このようにして、それらを単一のオブジェクトとして扱うことができます (これは、ファイルとディレクトリが何であるかを考えるときに理にかなっています。たとえば、Unix ではすべてがファイルです)。

したがって、この例では、Directory クラスの GetFiles() メソッドがありますが、File クラスはこのメソッドを実装しません。実装する意味がないからです。File には Directory のように子がないため、代わりに NotImplementedException が返されます。

これは .NET に限定されないことに注意してください。このパターンは、多くの OO 言語およびプラットフォームで見られます。

score 5 · Accepted Answer

NotImplementedExceptionを実際にキャッチする理由は実際にはありません。ヒットすると、アプリが強制終了され、非常に苦痛になります。それを修正する唯一の方法は、それをキャッチすることではなく、ソースコードを変更することです（呼び出されたメソッドを実装するか、呼び出し元のコードを変更します）。

score 5 · Accepted Answer

考えられるすべての例外をキャッチする必要があると感じるのはなぜですか? すべてのメソッド呼び出しもラップしcatch (NullReferenceException ex)ますか?

スタブコードのスローNotImplementedExceptionはプレースホルダーです。リリースする場合は、のようにバグにする必要がありますNullReferenceException。

score 5 · Accepted Answer

MS が NotImplementedException をフレームワークに追加した理由はたくさんあると思います。

便宜上; 多くの開発者が開発中にそれを必要とするのに、なぜ誰もが自分でロールバックしなければならないのでしょうか?
ツールがその存在に依存できるように。たとえば、Visual Studio の "Implement Interface" コマンドは、NotImplementedException をスローするメソッドスタブを生成します。フレームワークに含まれていない場合、これは不可能であるか、少なくとも厄介です (たとえば、独自の NotImplementedException を追加するまでコンパイルされないコードが生成される可能性があります)。
一貫した「標準的な慣行」を奨励する

Frankodwyer は、NotImplementedException を潜在的な時限爆弾と考えています。未完成のコードは時限爆弾だと思いますが、NotImplementedException は代替手段よりもはるかに簡単に武装解除できます。たとえば、ビルドサーバーに、このクラスのすべての使用についてソースコードをスキャンさせ、それらを警告として報告させることができます。本当に禁止したい場合は、そのようなコードのチェックインを防ぐ pre-commit フックをソース管理システムに追加することもできます。

確かに、独自の NotImplementedException をロールする場合は、最終ビルドからそれを削除して、時限爆弾が残らないようにすることができます。ただし、これはチーム全体で独自の実装を一貫して使用する場合にのみ機能し、リリースする前に削除することを忘れないようにする必要があります。また、削除できない場合もあります。たとえば、顧客に出荷されていないコードのテストなど、いくつかの許容される用途があるかもしれません。

score 4 · Accepted Answer

2 つの理由:

メソッドは開発中にスタブ化され、例外をスローして、コードの記述が完了していないことを開発者に思い出させます。
設計上、継承された基本クラスまたはインターフェイスの 1 つ以上のメソッドを実装しないサブクラスインターフェイスを実装する。(一部のインターフェースは一般的すぎます。)

score 3 · Accepted Answer

COM相互運用にはこの例外が必要です。E_NOTIMPLです。リンクされたブログには他の理由も示されています

score 3 · Accepted Answer

スローNotImplementedExceptionは、IDEがコンパイルスタブコードを生成するための最も論理的な方法です。インターフェイスを拡張して、VisualStudioにスタブを作成させる場合と同様です。

少しC++/ COMを実行した場合、それはとして知られていることを除いて、そこにも存在していましたE_NOTIMPL。

それには有効なユースケースがあります。インターフェイスの特定のメソッドで作業している場合は、コードをコンパイルして、デバッグとテストを行うことができます。ロジックに応じて、インターフェイスからメソッドを削除し、コンパイルされていないスタブコードをコメントアウトする必要があります。これは非常に原理主義的なアプローチであり、メリットはありますが、誰もがそれに固執する、または固執する必要があるわけではありません。その上、ほとんどの場合、インターフェースを完成させたいと思うでしょう。

NotImplementedExceptionを使用すると、まだ準備ができていないメソッドを適切に識別できCtrl+Shift+Fます。結局のところ、すべてを見つけるのと同じくらい簡単です。静的コード分析ツールでもそれを検出できると確信しています。

NotImplementedException例外のあるコードを出荷することを意図したものではありません。それを使用しないことでコードを改善できると思うなら、先に進んでください。しかし、ソースの品質を改善するためにできるより生産的なことがあります。

score 3 · Accepted Answer

これは私にとって潜在的な地雷原のように聞こえます。遠い昔、私はかつて、何年もノンストップで稼働していたレガシーネットワークシステムを 1 日で停止したことがあります。問題を追跡したところ、明らかに完成していないコードが見つかりました。これは文字通り、プログラマーがコーディング中に中断されたように、まったく機能しませんでした。この特定のコードパスがこれまで使用されたことがないことは明らかでした。

マーフィーの法則によれば、NotImplementedException の場合にも同様のことが起こりそうです。TDDなどの最近では、リリース前に取得する必要があり、少なくともリリース前にその例外のコードをgrepできますが、それでも.

テストするとき、すべてのケースのカバレッジを保証することは困難です。これは、コンパイル時の問題であった可能性のあるものを実行時の問題にすることで、仕事を難しくしているように思えます。(「ダックタイピング」に大きく依存するシステムには、同様の「技術的負債」が伴うと思いますが、それらが非常に有用であることは認めています)。

score 2 · Accepted Answer

プロダクションコードにこのメソッドがあるとしましょう

public void DoSomething()

後で完成させるために残したい場合は、どちらを選びますか？

public void DoSomething()
{
}

また

public void DoSomething()
{
    throw new NotImplementedException();
}

私は確かに2番目を取るでしょう。Elmahまたはお持ちのエラーロギングメカニズム（アプリケーション全体のアスペクトとして実装）と組み合わせる。ログ/例外フィルタリングとともに、キャッチされたときに重大なエラーの電子メール通知をトリガーします。

NotImplementedException==unfinishedという引数も正しくありません。（1）実装されていないメソッドのキャッチは、単体テスト/統合テストに任せる必要があります。NotImplementedExceptionのない100％のカバレッジ（これは、非常に多くのモック/スタブ/コード生成ツールを使用して行う必要があります）がある場合、どのような心配がありますか？（2）コード生成。シンプルでわかりやすい。繰り返しますが、コードを生成し、生成されたコードの半分しか使用しない場合、生成されたスタブの残りの部分にNotImplementedExceptionがないのはなぜですか？

これは、null許容のすべての入力がnullであるかどうかをチェック/処理する必要がない限り、コードをコンパイルすべきではないと言っているようなものです。（別名、1兆ドルの間違い、それ以上ではないにしても）。言語は柔軟でなければなりませんが、テスト/契約はしっかりしている必要があります。

score 2 · Accepted Answer

ECMA-335、CLI 仕様、具体的には CLI ライブラリタイプ、System.NotImplementedException、備考セクションから:

「この標準の他の場所で指定されている多くの型と構成要素は、カーネルプロファイルのみに準拠する CLI 実装には必要ありません。たとえば、浮動小数点機能セットは、浮動小数点データ型 System.Single と System.Single で構成されます。 System.Double。これらのサポートが実装から省略されている場合、浮動小数点データ型を含むシグネチャを参照しようとすると、System.NotImplementedException 型の例外が発生します。」

したがって、例外は、最小限の適合プロファイルのみを実装する実装を対象としています。最低限必要なプロファイルは、カーネルプロファイル (ECMA-335 第 4 版 - パーティション IV、セクション 3 を参照) です。これには BCL が含まれます。これが、例外が「コア API」に含まれ、他の場所には含まれない理由です。

スタブ化されたメソッドを示すために例外を使用したり、デザイナーが生成したメソッドが実装されていない場合、例外の意図を誤解することになります。

MS の CLI の実装に関する MSDN ドキュメントにこの情報が含まれていない理由については、私にはわかりません。

score 2 · Accepted Answer

NotImplementedException を保証することはできませんが (私はあなたの意見にほぼ同意します)、職場で使用するコアライブラリで NotSupportedException を広く使用しています。たとえば、DatabaseController を使用すると、サポートされている任意のタイプのデータベースを作成し、その下にあるデータベースのタイプをあまり気にせずに、残りのコード全体で DatabaseController クラスを使用できます。かなり基本的なものですよね？NotSupportedException が便利な場所 (および、実装がまだ存在しない場合に独自の実装を使用した場所) は、2 つの主要なインスタンスです。

1) アプリケーションを別のデータベースに移行するこれは、あったとしてもめったに起こらない、または必要になるとよく言われます。でたらめ。もっと出る。

2) 同じデータベース、異なるドライバーこれの最も最近の例は、Access ベースのアプリケーションを使用しているクライアントが WinXP から Win7 x64 にアップグレードしたときです。64 ビットの JET ドライバーではないため、IT 担当者は代わりに AccessDatabaseEngine をインストールしました。アプリがクラッシュしたとき、DB.Connect が NotSupportedException でクラッシュしたことをログから簡単に確認できました。これにはすぐに対処できました。もう 1 つの最近の例は、プログラマーの 1 人が Access データベースでトランザクションを使用しようとしたことです。Access はトランザクションをサポートしていますが、ライブラリは Access トランザクションをサポートしていません (理由はこの記事の範囲外です)。NotSupportedException、あなたが輝く時が来ました!

3) 一般的な機能ここでは「経験から」簡潔な例を思いつきませんが、電子メールに添付ファイルを追加する機能のようなものを考えると、JPEG のようないくつかの一般的なファイルを取得できるようにする必要があります。さまざまなストリームクラスから派生したもの、および「.ToString」メソッドを持つ事実上すべてのもの。後半では、考えられるすべてのタイプを明らかにすることはできないため、ジェネリックにします。ユーザーが OurCrazyDataTypeForContainingProprietarySpreadsheetData を渡すと、リフレクションを使用して ToString メソッドの存在をテストし、NotSupportedException を返して、ToString をサポートしないデータ型がサポートされていないことを示します。

NotSupportedException は決して重要な機能ではありませんが、大規模なプロジェクトに取り組むにつれて、より多くの機能を使用していることに気づきました。

score 2 · Accepted Answer

NotImplementedException

要求されたメソッドまたは操作が実装されていない場合、例外がスローされます。

これを .NET コアで定義された単一の例外にすることで、それらを見つけて根絶することが容易になります。すべての開発者が独自のものを作成する必要がある場合ACME.EmaNymton.NotImplementedException、それらすべてを見つけるのは難しくなります。

サポートされていない例外

呼び出されたメソッドがサポートされていない場合、例外がスローされます。

たとえば、呼び出された機能をサポートしていないストリームの読み取り、シーク、または書き込みが試行された場合などです。

たとえば、（yieldキーワードを使用して）生成されたイテレータは-a ですIEnumeratorが、IEnumerator.ResetメソッドはをスローしNotSupportedExceptionます。

score 1 · Accepted Answer

インターフェイスの修正に使用することはめったにありません。準拠する必要があるインターフェイスがあると仮定しますが、特定のメソッドは誰にも呼び出されないため、NotImplementedException を貼り付けるだけで、誰かがそれを呼び出した場合、彼らは何か間違ったことをしていることがわかります。

score 1 · Accepted Answer

どちらも、2 つの一般的な問題に対するハックです。

NotImplementedException は、アーキテクチャの宇宙飛行士であり、最初に API を書き留め、後でコーディングすることを好む開発者向けの回避策です。明らかに、これは段階的なプロセスではないため、一度にすべてを実装することはできません。

NotSupportedException は、C# や Java に見られるような型システムの制限をハックしたものです。これらの型システムでは、Rectangle はすべての Shape 特性 (メンバー関数 + 変数を含む) を継承する場合、Rectangle は Shape であると言います。しかし、実際にはそうではありません。たとえば、Square は Rectangle ですが、Square は Rectangle の制限であり、一般化ではありません。

したがって、親クラスの動作を継承して制限したい場合は、制限に意味をなさないメソッドに NotSupported をスローします。

score 1 · Accepted Answer

.NET の一部のメソッドに対して NotImplementedException がスローされます (コード DOM のパーサー C# を参照してください。これは実装されていませんが、メソッドは存在します!) このメソッドで確認できます Microsoft.CSharp.CSharpCodeProvider.Parse

score 0 · Accepted Answer

NotImplementedExceptionは、開発を容易にするためにのみ存在します。インターフェイスの実装を開始するとします。次のメソッドに移動する前に、少なくとも1つのメソッドの実装が完了したら、ビルドできるようにする必要があります。NotImplementedメソッドをNotImplementedExceptionsでスタブ化することは、後で見つけるのが非常に簡単な未完成のコードを生きる素晴らしい方法です。そうしないと、修正するのを忘れる可能性のあるものをすばやく実装するリスクがあります。

score 0 · Accepted Answer

プロトタイプや未完成のプロジェクトはどうですか?

例外を使用するのが本当に悪い考えだとは思いません (その場合はメッセージボックスを使用しますが)。

score 0 · Accepted Answer

うーん、なんとなく納得。すべてのクラスがそのすべてのビットを実装できるわけではないような方法でインターフェイスが作成された場合、私の意見では、それは分解されるべきでした。

IList を変更できる場合と変更できない場合は、2 つに分割する必要があります。1 つは変更できない部分 (ゲッター、ルックアップなど) 用で、もう 1 つは変更可能な部分 (セッター、追加、削除など) 用です。

score 0 · Accepted Answer

私のコードにはいくつかの NotImplementedExceptions があります。多くの場合、インターフェイスまたは抽象クラスの一部から発生します。将来必要になると思われるいくつかのメソッドは、クラスの一部として理にかなっていますが、実際に必要でない限り、時間をかけて追加したくありません。たとえば、ゲーム内の個々の種類のすべての統計用のインターフェイスがあります。これらの種類の 1 つは ModStat です。これは、基本統計とすべての修飾子 (つまり、武器、防具、呪文) の合計です。私の統計インターフェイスには OnChanged イベントがありますが、私の ModStat は、呼び出されるたびに参照するすべての統計の合計を計算することによって機能します。したがって、統計が変更されるたびに大量の ModStat.OnChange イベントが発生するというオーバーヘッドを発生させる代わりに、誰かが OnChange にリスナーを追加/削除しようとすると、NotImplementedException をスローするだけです。

.NET 言語は生産性がすべてです。では、使用することのないもののコーディングに時間を費やす必要はありません。

score 0 · Accepted Answer

一例を次に示します。Java では、インターフェースを実装するたびに、明らかなメソッドおよびIteratorをオーバーライドする必要がありますが、もあります。私が持っているユースケースの99％では、これは必要ないので、. これは、黙って何もしないよりははるかに優れています。hasNext()next()delete()NotImplementedException

score -1 · Accepted Answer

使いたくない場合は無視してください。コードブロックの成功は、そのすべての部分の成功に依存しているが、途中で失敗する可能性がある場合、唯一のオプションは、ベースをキャッチしてException、ロールバックする必要があるものをロールバックすることです。忘れてくださいNotImplementedException。MyRandomExceptionやなど、大量の例外がスローされる可能性がありGtfoExceptionますOmgLolException。あなたが最初にコードを書いた後、あなたが呼び出している API から別の例外タイプをスローすることができました。コードを書いたときに存在しなかったもの。処理方法を知っているものを処理し、他のものをロールバックしますcatch(Exception)。とてもシンプルだと思います...便利だと思います。特に、言語やフレームワークを使って派手なことをしようとしているときは特に、時折強制されることがあります。

私が持っている一例はシリアライゼーションです。データベースに存在しないプロパティを .NET ライブラリに追加しました (たとえば、、、およびFullNameを組み合わせたプロパティなど、既存の「ダム」プロパティに対する便利なラッパー)。次に、これらのデータ型を XML にシリアル化してネットワーク経由で (たとえば、ASP.NET アプリケーションから JavaScript に) 送信したいと考えていますが、シリアル化フレームワークは、とアクセサーの両方を持つパブリックプロパティのみをシリアル化します。設定できるようにしたくありません。解析する必要があり、予期しない形式が誤って解析され、データの整合性が失われる可能性があるためです。基礎となるプロパティを使用する方が簡単ですが、言語と API にはFirstNameMiddleNameLastNamegetsetFullNamesetアクセサーをスローします(このスレッドを読むまでNotImplementedExceptionは気が付きませんでしたが、どちらでも機能します)。これにより、途中でプログラマーが設定しようとすると、テスト中に例外に遭遇し、自分の間違いに気付くでしょう。NotSupportedExceptionFullName

.net - NotImplementedException が存在するのはなぜですか?

27 に答える 27

Related

Reference