質問

これは本当に私を非常に困らせるので、誰かが私が物事がなぜあるのかについて合理的な正当化を与えることができることを願っています。

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

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

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

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

おかしいよ。マッド。とんでもない。質問は次のとおりです。 NotImplementedExceptionが存在する理由

先制攻撃として、「設計者はこれを自動生成コードに含める必要があるため」誰にも返事を望まない。これは恐ろしいです。自動生成されたコードは、実装を提供するまでコンパイルしません。たとえば、自動生成された実装は、「Throw NotImplementedException;」のようになります。 NotImplementedExceptionが定義されていない場合!

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

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

追加情報:

これはこのテーマに関する興味深い読み物です。

ブラッドエイブラムスとは強力な合意があるようです⫬ NotImplementedExceptionは、まだ実装されていない機能向けですが、実際に実装する必要があります(実際に実装される予定です)。クラスを構築するときに開始し、NotImplementedExceptionをスローするすべてのメソッドを取得してから、実際のコードでそれらをフラッシュします…"

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

MSDN は、この件についてはさらに弱く、単に「要求されたメソッドまたは操作が実装されていないときにスローされる例外」

役に立ちましたか?

解決

有用な状況は1つあります。TDDです。

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

他の状況で NotImplementedException を使用することはないため、常にテストが失敗するため、 NotImplementedException はリリースコードに渡されません。

あちこちで捕まえる必要はありません。優れた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>

これをビルドするには、次のことが必要です。

  • reference Microsoft.FxCop.Sdk.dll および Microsoft.Cci.dll

  • メタデータを DesignRules.xml というファイルに入れ、それを組み込みリソースとしてアセンブリに追加します

  • アセンブリに Bevonn.CodeAnalysis という名前を付けます。メタデータファイルまたはアセンブリファイルに異なる名前を使用する場合は、それに応じて2番目のパラメーターをベースコンストラクターに変更してください。

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

他のヒント

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

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

でそれを知らせることができます

いくつかのコメントに散らばっているので、これに関する私の見解を1か所にまとめます。

  1. NotImplementedException を使用して、インターフェイスメンバがまだ実装されていないが実装されることを示します。これを自動化された単体テストまたはQAテストと組み合わせて、実装が必要な機能を特定します。

  2. この機能が実装されたら、 NotImplementedException を削除します。機能に対して適切に機能することを確認するための新しい単体テストが作成されています。

  3. NotSupportedException は、通常、特定のタイプに意味のない機能をサポートしないプロバイダーに使用されます。そのような場合、特定のタイプは例外をスローし、クライアントはそれらをキャッチし、必要に応じて処理します。

  4. フレームワークに NotImplementedException NotSupportedException の両方が存在する理由は単純です:それらにつながる状況は一般的であるため、それらを定義するのが理にかなっています開発者がそれらを再定義し続ける必要がないように、フレームワークで。また、クライアントがどの例外をキャッチするかを簡単に知ることができます(特に単体テストのコンテキストで)。独自の例外を定義する必要がある場合、どの例外をキャッチするかを把握する必要があります。これは、少なくとも非生産的なタイムシンクであり、頻繁に間違っています。

  

NotImplementedExceptionが発生する理由   存在しますか?

NotImplementedExceptionは、まだ準備ができていないことを示す素晴らしい方法です。なぜ準備ができていないのかは、メソッドの作成者にとって別の質問です。実動コードでは、この例外をキャッチすることはまずありませんが、実際に何が起こったのかをすぐに確認でき、メソッドが呼び出されたが何も起こらなかった、またはさらに悪いことを理解するよりもはるかに優れています-「一時的な」結果と「面白い」を得る;副作用。

  

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

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

  

アルゴリズムを実行する必要があります、キャッチ   NotImplementedExceptionsおよびいくつか   アプリケーションをどのようにロールバックするか   健全な状態

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

  

私は非常に疑っています   NotSupportedExceptionも... Not   サポートされていますか?なに?そうでない場合   サポートされている、なぜあなたの一部ですか   インターフェース?

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

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

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

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

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

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

したがって、この例では、DirectoryクラスのGetFiles()メソッドがありますが、Fileクラスはこのメソッドを実装しません。代わりに、ファイルにはディレクトリのように子がないため、NotImplementedExceptionが発生します。

これは.NETに限定されないことに注意してください-多くのオブジェクト指向言語とプラットフォームでこのパターンに出くわすでしょう。

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

NotImplementedException をスローするスタブコードはプレースホルダーです。リリースするようにすると、 NullReferenceException と同様にバグになるはずです。

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

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

Frankodwyerは、NotImplementedExceptionを潜在的な時限爆弾と考えています。未完成のコードは時限爆弾であると言えますが、NotImplementedExceptionは他の方法よりも簡単に解除できます。たとえば、ビルドサーバーでこのクラスのすべての使用についてソースコードをスキャンし、警告として報告することができます。本当に禁止したい場合は、ソース管理システムにプリコミットフックを追加して、そのようなコードのチェックインを防ぐこともできます。

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

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

2つの理由:

  1. メソッドは開発中にスタブ化され、例外をスローして、コードの作成が終了していないことを開発者に思い出させます。

  2. サブクラスインターフェイスを実装します。これは、設計上、継承された基本クラスまたはインターフェイスの1つ以上のメソッドを実装しません。 (一部のインターフェースは一般的すぎます。)

これは、私にとって潜在的な地雷原のように聞こえます。遠い昔、私はかつて何年もの間ノンストップで稼働していて、1日で倒れたレガシーネットワークシステムで働いていました。問題を突き止めたところ、明らかに終了しておらず、動作しなかったコードがいくつか見つかりました-文字通り、コーディング中にプログラマーが割り込んだようなものです。この特定のコードパスがこれまで使用されたことがないことは明らかでした。

マーフィーの法則によれば、NotImplementedExceptionの場合には、同様のことが起きようとしています。最近のTDDなどで認められているように、リリース前にピックアップする必要があります。少なくとも、リリース前にその例外のコードをgrepできますが、それでも可能です。

テストする場合、すべてのケースのカバレッジを保証することは難しく、これはコンパイル時の問題の実行時の問題を作成することにより、あなたの仕事を難しくするように聞こえます。 (同様の種類の「技術的負債」は、「ダックタイピング」に大きく依存するシステムに付属すると思いますが、非常に有用であると認識しています)

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

NotImplementedException をスローすることは、IDEがコンパイルスタブコードを生成する最も論理的な方法です。インターフェイスを拡張し、Visual Studioにスタブを作成するときのように。

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

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

NotImplementedExceptionを持っていると、まだ準備ができていないメソッドを識別できます。1日の終わりには、 Ctrl + Shift + F を押してすべてのメソッドを見つけるのと同じくらい簡単です。分析ツールもそれを拾います。

NotImplementedException 例外があるコードを出荷するつもりはありません。使用しないことでコードを改善できると思う場合は、先に進みますが、ソースの品質を改善するためにできる生産性の高い方法があります。

NotImplementedException

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

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

NotSupportedException

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

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

インスタンス生成イテレータの場合( yield キーワードを使用)is-a IEnumerator ですが、 IEnumerator.Reset メソッドは NotSupportedException

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

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

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

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

この情報がMSのCLI実装のMSDNドキュメントに含まれていない理由については、私を超えています。

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

1)アプリケーションを別のデータベースに移行する 多くの場合、これが発生するか、必要になることはめったにありません。 Bullsh * t。詳細をご覧ください。

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

3)汎用関数 簡潔な「経験から」を考えることはできません。ここでの例ですが、メールに添付ファイルを追加する関数のようなものを考える場合、JPEG、さまざまなストリームクラスから派生したもの、および&quot;を持つ実質的にすべてのようないくつかの一般的なファイルを取得できるようにします。 ToString&quot;方法。後者については、すべての可能なタイプを確実に説明することはできないので、一般的なタイプにします。ユーザーがOurCrazyDataTypeForContainingProprietarySpreadsheetDataを渡すと、リフレクションを使用してToStringメソッドの存在をテストし、NotSupportedExceptionを返して、ToStringをサポートしないデータ型のサポートがないことを示します。

NotSupportedExceptionは決して重要な機能ではありませんが、大規模なプロジェクトに取り組んでいるときはもっと多く使用しています。

本番コードにこのメソッドがあるとしましょう

public void DoSomething()

後で終了して終了する場合、どちらを選択しますか?

public void DoSomething()
{
}

または

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

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

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

すべてのnull入力がnullに対してチェック/処理される必要がある場合を除き、コードをコンパイルしないと言っているようなものです。 (別名、1兆ドル以上の間違い)。言語は柔軟でなければなりませんが、テスト/契約は堅固でなければなりません。

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

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

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

NotImplementedExceptionは、アーキテクチャの宇宙飛行士であり、最初にAPIを書き、後でコードを書きたい開発者向けの回避策です。明らかに、これはインクリメンタルプロセスではないため、一度にすべてを実装することはできません。したがって、NotImplementedExceptionをスローすることで半完了のふりをしたいです。

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

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

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

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

まあ、私はいくらか同意します。すべてのクラスがすべてのクラスを実装できるわけではないような方法でインターフェースが作成された場合、私の意見では分解されるはずです。

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

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

.NET言語はすべて生産性に関するものであるため、使用しないもののコーディングに時間を費やすのはなぜですか?

1つの例を次に示します。Javaでは、インターフェイス Iterator を実装するたびに、明白なメソッド hasNext()および next()<をオーバーライドする必要があります。 / code>、ただし delete()もあります。私が持っているユースケースの99%ではこれは必要ないので、 NotImplementedException をスローするだけです。これは静かに何もしないよりもはるかに優れています。

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

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

私が持っている1つの例は、シリアル化です。データベースに存在しないプロパティを.NETライブラリに追加しました(たとえば、 FirstName FullName プロパティなど、既存の&quot; dumb&quot;プロパティの便利なラッパーcode>、 MiddleName 、および LastName )。次に、これらのデータ型をXMLにシリアル化して、ASP.NETアプリケーションからJavaScriptに送信しますが、シリアル化フレームワークは get と< code> set アクセサー。 FullName を設定できるようにしたくないのは、それを解析する必要があり、誤って解析してデータの整合性がウィンドウから外れてしまうような予期しないフォーマットがあるかもしれないからです。基礎となるプロパティを使用する方が簡単ですが、言語とAPIには set アクセサーが必要なので、 NotImplementedException をスローします(このスレッドを読むまで NotSupportedException を認識しますが、いずれかが動作します)将来プログラマーが FullName を設定しようとすると、テスト中に例外が発生し彼の間違いに気づきます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top