例外の安全性のために「スコープ付きの動作」を取得する手段としてIDisposableおよび「using」を使用することは悪用ですか？

私がC ++でよく使用したのは、コンストラクターとデストラクターを使用して、AクラスBに別のクラスの状態の開始条件と終了条件を処理させ、Aそのスコープ内の何かが例外をスローした場合にBが既知の状態になるようにすることでした。スコープが終了しました。これは頭​​字語に関する限り、純粋なRAIIではありませんが、それでも確立されたパターンです。

C＃では、よくやりたい

class FrobbleManager
{
    ...

    private void FiddleTheFrobble()
    {
        this.Frobble.Unlock();
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
        this.Frobble.Lock();
    }
}

このようにする必要があります

private void FiddleTheFrobble()
{
    this.Frobble.Unlock();

    try
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
    finally
    {
        this.Frobble.Lock();
    }
}

返品Frobble時の状態を保証したい場合FiddleTheFrobble。コードはより良いでしょう

private void FiddleTheFrobble()
{
    using (var janitor = new FrobbleJanitor(this.Frobble))
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
}

どこFrobbleJanitorルックスおおよそのような

class FrobbleJanitor : IDisposable
{
    private Frobble frobble;

    public FrobbleJanitor(Frobble frobble)
    {
        this.frobble = frobble;
        this.frobble.Unlock();
    }

    public void Dispose()
    {
        this.frobble.Lock();
    }
}

それが私がやりたいことです。私はので、今の現実は、追いつくたい使用する必要があることFrobbleJanitorに使用されて using。私はこれをコードレビューの問題と考えることができましたが、何かが私を悩ませています。

質問：上記はusingandの乱用と見なされIDisposableますか？

必ずしもそうは思いません。IDisposableは、技術的には非管理対象リソースを持つものに使用することを目的としていますが、usingディレクティブは、の一般的なパターンを実装するためのきちんとした方法ですtry .. finally { dispose }。

純粋主義者は「はい-それは虐待的です」と主張し、純粋主義的な意味ではそうです。しかし、私たちのほとんどは、純粋主義的な観点からではなく、半芸術的な観点からコーディングを行っています。私の意見では、このように「using」コンストラクトを使用することは、非常に芸術的です。

おそらく、IDisposableの上に別のインターフェイスを貼り付けて、少し離れて、そのインターフェイスがIDisposableを意味する理由を他の開発者に説明する必要があります。

これを実行する方法は他にもたくさんありますが、結局のところ、これほど優れた方法は考えられません。

これは、usingステートメントの乱用だと思います。私はこの立場で少数派であることを知っています。

私はこれを3つの理由で虐待だと考えています。

1つ目は、「using」はリソースの使用に使用され、使い終わったらそれを破棄することを期待しているためです。プログラムの状態を変更してもリソースは使用されず、リソースを元に戻しても何も処理されません。したがって、状態を変更および復元するために「使用」することは不正行為です。コードはカジュアルな読者を誤解させます。

第二に、私は「使用する」ことは礼儀正しさからではなく、必要ではないことを期待しているからです。使い終わったときに「を使用して」ファイルを破棄する理由は、ファイルを破棄する必要があるからではなく、礼儀正しいためです。誰かがそのファイルの使用を待っている可能性があるため、「完了」と言います今」は道徳的に正しいことです。私は、「使用」をリファクタリングして、使用されたリソースをより長く保持し、後で破棄できるようにすべきであり、そうすることの唯一の影響は、他のプロセスにわずかに不便をかけることです。プログラムの状態に意味的な影響を与える「using」ブロック 必要とせずに、便利で丁寧にあるように見える構造にプログラム状態の重要で必要な変更を隠すため、乱用されます。

そして3番目に、プログラムのアクションはその状態によって決定されます。状態を注意深く操作する必要があるため、そもそもこの会話をしているのです。元のプログラムを分析する方法を考えてみましょう。

これを私のオフィスのコードレビューに持ち込んだ場合、私が最初に尋ねる質問は、「例外がスローされた場合に、フロブルをロックすることは本当に正しいのか？」です。何が起こっても、これが積極的にフロブルを再ロックすることは、プログラムから明らかに明白です。そうですか？ 例外がスローされました。プログラムは不明な状態です。Foo、Fiddle、またはBarがスローしたかどうか、なぜスローしたか、クリーンアップされなかった他の状態に対してどのミューテーションを実行したかはわかりません。その恐ろしい状況では、再ロックすることは常に正しいことだと私に納得させることができますか？

たぶんそうかもしれませんし、そうでないかもしれません。私の要点は、コードが最初に書かれたとおりの場合、コードレビューアは質問をすることを知っているということです。"using"を使用するコードでは、質問をするかどうかわかりません。私はそれが行われたとき、それのブロックは、リソースを割り当て、ビットのためにそれを使用し、丁寧に処分「を使用して」と仮定し、いないよう閉じ括弧ブロック「を使用する」の際に任意の数の例外cirumstanceに変異する私のプログラムの状態をプログラム状態の整合性条件に違反しています。

「using」ブロックを使用してセマンティック効果を持たせると、このプログラムが断片化されます。

}

非常に意味があります。その単一の閉じ波括弧を見るとき、「その波括弧には私のプログラムのグローバルな状態に大きな影響を与える副作用がある」とすぐには思いません。しかし、このように「使用」を乱用すると、突然使用されます。

元のコードを見た場合に2番目に尋ねるのは、「Unlockの後で、tryに入る前に例外がスローされた場合はどうなるのか」ということです。最適化されていないアセンブリを実行している場合、コンパイラーは試行の前にno-op命令を挿入した可能性があり、no-opでスレッドアボート例外が発生する可能性があります。これはまれですが、実際には、特にWebサーバーで発生します。その場合、ロック解除は発生しますが、試行の前に例外がスローされたため、ロックは発生しません。このコードはこの問題に対して脆弱である可能性があり、実際に作成する必要があります

bool needsLock = false;
try
{
    // must be carefully written so that needsLock is set
    // if and only if the unlock happened:

    this.Frobble.AtomicUnlock(ref needsLock);
    blah blah blah
}
finally
{
    if (needsLock) this.Frobble.Lock();
}

繰り返しますが、そうかもしれませんし、そうでないかもしれませんが、私は質問することを知っています。"using"バージョンでは、同じ問題の影響を受けやすくなります。Frobbleがロックされた後、usingに関連付けられたtry保護領域に入る前に、スレッドアボート例外がスローされる可能性があります。しかし、「使用中」バージョンでは、これは「だから何だ」と思います。状況。それが起こった場合は残念ですが、「使用する」ことは、非常に重要なプログラムの状態を変更するのではなく、丁寧にするためだけにあると思います。ひどいスレッドアボート例外がまったく間違ったタイミングで発生した場合、ガベージコレクターはファイナライザーを実行して最終的にそのリソースをクリーンアップすると思います。

クリーンでスコープのあるコードが必要な場合は、ラムダを使用することもできます。

myFribble.SafeExecute(() =>
    {
        myFribble.DangerDanger();
        myFribble.LiveOnTheEdge();
    });

ここで、.SafeExecute(Action fribbleAction)本方法は、ラップtry- catch- finallyブロック。

C＃言語設計チームに所属していたエリックガナーソンは、ほぼ同じ質問に対してこの答えを出しました。

ダグは尋ねます：

re：タイムアウトのあるロックステートメント...

数多くのメソッドで共通のパターンを処理するために、以前にこのトリックを実行しました。通常はロック取得ですが、他にもいくつかあります。問題は、オブジェクトが「スコープの終わりでのコールバック」ほど実際には使い捨てではないため、常にハックのように感じられることです。

ダグ、

usingステートメントを決定したとき、このシナリオに正確に使用できるように、オブジェクトの配置に特定のものではなく、「using」という名前を付けることにしました。

滑りやすい坂道です。IDisposableには契約があり、ファイナライザによってバックアップされています。ファイナライザはあなたの場合には役に立ちません。クライアントにusingステートメントの使用を強制することはできません。使用するように勧めるだけです。次のような方法で強制できます。

void UseMeUnlocked(Action callback) {
  Unlock();
  try {
    callback();
  }
  finally {
    Lock();
  }
}

しかし、それはラムダなしでは少し厄介になる傾向があります。そうは言っても、私はあなたがしたようにIDisposableを使用しました。

しかし、あなたの投稿には、これを危険なほどアンチパターンに近づける詳細があります。あなたはそれらのメソッドが例外を投げることができると述べました。これは発信者が無視できるものではありません。彼はそれに関して3つのことをすることができます：

• 何もしないでください。例外は回復できません。通常の場合。Unlockの呼び出しは重要ではありません。
• 例外をキャッチして処理する
• 彼のコードで状態を復元し、例外に呼び出しチェーンを渡させます。

後者の2つでは、呼び出し元が明示的にtryブロックを書き込む必要があります。これで、usingステートメントが邪魔になります。クライアントが昏睡状態に陥り、あなたのクラスが国家の面倒を見ていて、追加の作業を行う必要がないと彼に思わせるかもしれません。それはほとんど正確ではありません。

実際の例は、ASP.net MVCのBeginFormです。基本的にあなたは書くことができます：

Html.BeginForm(...);
Html.TextBox(...);
Html.EndForm();

または

using(Html.BeginForm(...)){
    Html.TextBox(...);
}

Html.EndFormはDisposeを呼び出し、Disposeは</form>タグを出力するだけです。これの良い点は、{}ブラケットが目に見える「スコープ」を作成することです。これにより、フォーム内にあるものとないものを簡単に確認できます。

私はそれを使いすぎませんが、本質的にIDisposableは、「この関数を使い終わったら、この関数を呼び出さなければならない」と言うだけの方法です。MvcFormはそれを使用してフォームが閉じていることを確認し、Streamはそれを使用してストリームが閉じていることを確認します。これを使用してオブジェクトがロック解除されていることを確認できます。

個人的には、次の2つのルールが当てはまる場合にのみ使用しますが、これらは私が任意に設定します。

• Disposeは常に実行する必要がある関数であるため、Null-Checks以外の条件はありません。
• Dispose（）の後、オブジェクトは再利用できません。再利用可能なオブジェクトが必要な場合は、破棄するのではなく、オープン/クローズメソッドを指定します。そのため、破棄されたオブジェクトを使用しようとすると、InvalidOperationExceptionがスローされます。

最後に、それは期待についてのすべてです。オブジェクトがIDisposableを実装している場合は、クリーンアップを行う必要があると思いますので、それを呼び出します。私は通常、「シャットダウン」機能を持っているよりも優れていると思います。

そうは言っても、この行は好きではありません。

this.Frobble.Fiddle();

FrobbleJanitorがFrobbleを「所有」しているので、代わりに管理人のFrobbleでFiddleを呼び出す方が良いのではないでしょうか。

このパターンはコードベースで十分に使用されており、以前から至る所で見たことがあります。きっとここでも議論されているはずです。一般的に、これを行うことの何が悪いのかわかりません。これは、有用なパターンを提供し、実際に害を及ぼすことはありません。

これについて詳しく説明します。これは壊れやすいのですが有用であるという点で、私はほとんど同意しています。私はあなたを指すようにたいSystem.Transaction.TransactionScopeのあなたがしたいような何かをしたクラス、。

一般的に私は構文が好きです、それは本当の肉から多くの混乱を取り除きます。ただし、ヘルパークラスに適切な名前を付けることを検討してください-おそらく上記の例のように... Scopeです。名前は、コードの一部をカプセル化していることを示す必要があります。* Scope、* Block、または同様のものがそれを行うはずです。

注：私の視点はおそらくC ++の背景から偏っているので、私の答えの値はその可能な偏りに対して評価する必要があります...

C＃言語仕様とは何ですか？

C＃言語仕様の引用：

8.13 usingステートメント

[...]

リソースは廃棄という単一のパラメータのない方法を含む器具System.IDisposable、ことクラスまたは構造体です。リソースを使用しているコードは、Disposeを呼び出して、リソースが不要になったことを示すことができます。Disposeが呼び出されない場合、ガベージコレクションの結果として最終的に自動破棄が行われます。

リソースを使用しているコードは、もちろん、コードがによって開始されusingたキーワードに取り付けられた範囲まで行きますusing。

ロックはリソースなので、これは大丈夫だと思います。

おそらくキーワードのusing選択が悪かったのでしょう。多分それは呼ばれるべきscopedでした。

そうすれば、ほとんど何でもリソースと見なすことができます。ファイルハンドル。ネットワーク接続...スレッド？

スレッド???

usingキーワードを使用（または乱用）していますか？

それは次のようになり、光沢のある使用（AB）にusingしてくださいスレッドの仕事は、スコープを終了する前に終了させるためにキーワードを？

Herb Sutterは、スレッドの作業が終了するのを待つためのIDisposeパターンの興味深い使用法を提供しているため、それをピカピカだと思っているようです。

http://www.drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=225700095

以下は、記事からコピーして貼り付けたコードです。

// C# example
using( Active a = new Active() ) {    // creates private thread
       …
       a.SomeWork();                  // enqueues work
       …
       a.MoreWork();                   // enqueues work
       …
} // waits for work to complete and joins with private thread

ActiveオブジェクトのC＃コードは提供されていませんが、C ++バージョンがデストラクタに含まれているコードのIDisposeパターンをC＃が使用するように記述されています。そして、C ++バージョンを見ると、この記事の他の抜粋に示すように、終了する前に内部スレッドが終了するのを待つデストラクタが見つかります。

~Active() {
    // etc.
    thd->join();
 }

したがって、ハーブに関する限り、それは光沢があります。

私はあなたの質問に対する答えはノーだと思います、これはの乱用ではないでしょうIDisposable。

IDisposableインターフェイスを理解する方法は、オブジェクトが破棄された後はオブジェクトを操作することはできないということです（ただし、必要なだけDispose頻繁にそのメソッドを呼び出すことが許可されている場合を除きます）。

ステートメントに到達するたびに明示的に新しい オブジェクトを作成するため、同じオブジェクトを2回使用することはありません。また、その目的は別のオブジェクトを管理することであるため、この（「管理された」）リソースを解放するタスクに適しているようです。FrobbleJanitorusingFrobbeJanitorDispose

（ところで、Disposeファイルシステムハンドルなどのアンマネージリソースだけでなく、マネージリソースも解放する必要があることをほとんどの場合、適切な実装を示す標準サンプルコードで提案されています。）

私が個人的に心配する唯一のことは、＆操作が直接表示さusing (var janitor = new FrobbleJanitor())れるより明示的なtry..finallyブロックを使用するよりも、何が起こっているのかがはっきりしないことです。しかし、どちらのアプローチを取るかは、おそらく個人的な好みの問題に帰着します。LockUnlock

その虐待ではありません。あなたはそれらが作成された目的でそれらを使用しています。ただし、必要に応じて、次々と検討する必要があります。たとえば、 'artistry'を選択している場合は、 'using'を使用できますが、コードが何度も実行される場合は、パフォーマンス上の理由から、 'try' .. 'finally'構文を使用できます。「使用」には通常、オブジェクトの作成が含まれるためです。

あなたはそれを正しくやったと思います。Dispose（）のオーバーロードは、同じクラスが後で実際に実行する必要があるクリーンアップの問題であり、そのクリーンアップのライフタイムは、ロックを保持する予定の時間とは異なるものに変更されました。しかし、Frobbleのロックとロック解除のみを担当する別のクラス（FrobbleJanitor）を作成したため、問題が発生しないように、十分に分離されています。

ただし、おそらくFrobbleJanitorの名前をFrobbleLockSessionのような名前に変更します。