除外セキュリティ保証

エラー処理のエラーは、最も一般的なエラーの原因です。



この記事を書くときに気になったでたらめ



C＃でプログラミングする際に使用する方が良いものに関する主な戦い-例外または処理用のリターンコードは遠い過去にあります（*）が、別の種類の戦いはまだ収まりません：はい、まあ、例外処理に落ち着きましたが、どのように「正しく」処理しますか？



「正しい」ことについては多くの観点があり、その大部分は、処理可能な例外のみをキャッチし、残りを呼び出し元のコードにスローする必要があるという事実に要約されます。 わかりにくい例外が大胆な方法で上位レベルに到達した場合、最愛の人が一貫した状態であるかどうかが明確ではないため、アプリケーション全体を撮影します。



例外をキャッチして処理するこの方法には多くの長所と短所がありますが、今日は少し異なるトピックを検討します。 つまり、例外の発生に照らしてアプリケーションの一貫した状態を確保するというトピックは、例外に対する3つのセキュリティレベルです。

3種類の保証

1990年代後半、Dave Abrahamsは、3つのレベルの例外セキュリティを提供しました。基本保証、厳密保証、および例外なし保証です。 このアイデアは、開発者のC ++コミュニティに大歓迎され、Herb Sutterによる普及（および一部の変更）の後、例外セキュリティ保証がブースト、標準C ++ライブラリ、およびアプリケーション開発で広く使用され始めました。



当初、これらの保証はC ++でSTLPortライブラリを実装するためにDave Abrahamsによって提案されましたが、例外の安全性の考え方は特定のプログラミング言語に結び付けられておらず、JavaやC＃などの例外を主要なエラー処理メカニズムとして使用する他の言語で使用できます。 さらに、現在、例外セキュリティ定義には2つのバージョンがあります：（1）Dave Abrahamsによって提案された元のバージョンと（2）SatterおよびStraustrupによって普及した修正バージョンであり、ライブラリだけでなくアプリケーションアプリケーションにも適しています。

基本保証

初期定義 ：「 例外が発生した場合、リソースの漏洩はありません 。」



現代の定義は次のとおりです 。「 特定のメソッドで例外が発生した場合、プログラムの状態は一貫している必要があります 。」 これは、リソースリークがないことだけでなく、クラスの不変条件の保持も意味します。これは、基本的な定義と比較してより一般的な基準です。



これら2つの定式化の違いは、この保証はもともとC ++でライブラリを実装するために提案されたものであり、アプリケーションアプリケーションとは関係がないという事実によるものです。 しかし、より一般的なケース（つまり、ライブラリだけでなく、アプリケーションについても）について話すと、リソースリークはバグの原因の1つに過ぎず、バグの原因とは限りません。 任意の安定した時点（**）で不変式を保存することは、外部コードがアプリケーションの不一致状態を「見る」ことができないという保証です。これは、リソースリークがないことと同じくらい重要です。 ある口座から別の口座に送金するときに、ある口座からお金を「残す」ことはできても、別の口座に「届かない」場合、銀行アプリケーションのユーザーはほとんどメモリリークに興味を持ちません。

厳格な保証

例外の厳密な保証の定義については、元の定義と最新の定義は類似しており、次のように要約されます。「 操作中に例外が発生した場合、これはアプリケーションの状態に影響を与えません 」



言い換えれば、厳格な例外保証により、すべてを受け取ったとき、または何も受け取っていないときにトランザクションがトランザクションされることが保証されます。 この場合、例外が発生すると、操作前のアプリケーションの状態にロールバックし、操作全体が正常に完了した場合にのみ新しい状態に変更する必要があります。

除外は保証されていません

例外が存在しないことの保証は、「 どのような状況でも例外がスローされることはありません 」に限定されます 。



この保証は定義の点では最も単純ですが、見た目ほど単純ではありません。 まず、一般的な場合、特に.Net環境では、アプリケーションのほぼすべてのポイントで例外が発生する可能性があるため、提供することはほとんど不可能です。 実際には、運用単位のみがこの保証に従い、以前のレベルの保証が構築されるのはそのような運用に基づいています。 C＃では、この保証を提供する数少ない操作の1つはリンクの割り当てであり、C ++では、値の交換を実装するスワップ関数です。 これらの関数に基づいて、すべての「ダーティな作業」が一時オブジェクトで実行され、結果の値に割り当てられるときに、例外の厳密な保証がしばしば実現されます。



第二に、例外が存在しないという保証に従わない操作がある場合、他の機能の正常な操作を保証できない場合があります。 したがって、たとえば、C ++では、コンテナの例外（またはリソースリーク）の基本的な保証さえ提供するために、ユーザータイプのデストラクターが例外をスローしないことが必要です。



上記で説明した3つの例外のセキュリティ保証は、最も弱いものから最も強いものへと進みます。 以降の各保証は、前の保証のスーパーセットです。 これは、厳密な保証の履行は自動的に基本的な保証の履行を伴い、例外の不在の保証は厳密な保証の履行を伴うことを意味します。 コードが例外の基本的な保証さえも満たさない場合、それはアプリケーションの時限爆弾であり、遅かれ早かれ不快な結果につながり、その状態を地獄に壊します。



次に、いくつかの例を見てみましょう。

基本保証違反の例

C ++でのメモリおよびリソースリークを防ぐ主な方法はRAII （Resource Acquisition Is Initialization）イディオムです。これは、オブジェクトがコンストラクターでリソースを取得し、デストラクターでそれを解放するという事実から成ります。 また、例外が発生したときなど、何らかの理由でオブジェクトがスコープを離れるとデストラクタが自動的に呼び出されるため、例外の安全性を確保するために同じイディオムが使用されることは驚くことではありません。



C＃では、このイディオムはIDisposableインターフェイスとして移行し、コンストラクトを使用しますが、C ++とは異なり、特定のスコープ内のリソースのライフタイムの制御に適用でき、コンストラクターでキャプチャされた多くのリソースの管理には適していません。



例を見てみましょう：

// ,

class DisposableA : IDisposable

{

public void Dispose() {}

}



//

class DisposableB : IDisposable

{

public DisposableB()

{

disposableA = new DisposableA();

throw new Exception( "OOPS!" );

}



public void Dispose() {}



private DisposableA disposableA;

}



// -

using ( var disposable = new DisposableB())

{

// ! Dispose

// DisposableB, DisposableA

}



* This source code was highlighted with Source Code Highlighter .

そのため、 DisposableAとDisposableBの 2つの使い捨てクラスがあります。各クラスは、コンストラクターで一部の管理対象リソースをキャプチャし、 Disposeメソッドで解放します。 ファイナライザは、リソースの確定的なリリースを保証する助けにはならないため、現時点ではファイナライザを考慮しないようにしましょう。これは場合によっては不可欠です。



この場合、 DisposableBクラスのコンストラクターによって例外をスローするとき、 使い捨てオブジェクトが存在しなかったため、 Disposeメソッドを呼び出すことはありません。 この点で、ほとんどの主流のプログラミング言語の動作はほぼ同じですが、いくつかの違いがあります。 類似点は、コンストラクターが「クラッシュ」した場合、呼び出し元のコードはまだ構築されていないオブジェクトへのリンクを取得できず、そのリソースを明示的に解放できないことです。 ただし、完全に構築されたフィールドのデストラクタが自動的に呼び出されるC ++言語とは異なり、これは「マネージド」C＃言語（***）では発生しません。DisposableBクラスのコンストラクタが例外をスローし、以前にキャプチャしたリソースを解放しない場合、 「リソースの流出」（または、少なくとも非決定的リリース）を受け取ります。



同じ問題は、より微妙な形で現れます。 前に検討したケースでは、使い捨てオブジェクトのインスタンスを作成し、その後例外がスローされることがはっきりとわかります。 ただし、基本的な例外保証がないことを確認するのがもう少し難しい場合があります。

class Base : IDisposable

{

public Base()

{

//

}

public void Dispose() {}

}



class Derived : Base, IDisposable

{

public Derived( object data)

{

if (data == null )

throw new ArgumentNullException( "data" );

// OOPS!!

}

}

// -

using ( var derived = new Derived( null ))

{}



* This source code was highlighted with Source Code Highlighter .

Derivedクラスのコンストラクターで例外を生成すると、基本クラスのDisposeメソッドが呼び出されないため（****）、基本的な例外保証に違反し、リソースリークが発生します。 繰り返しますが、コンパイラはusing構造のプリズムを通してのみIDisposableインターフェイスを知っているため、すべての場合、使い捨てオブジェクトが別のクラスのフィールドである場合、プログラマのみがDisposeメソッドを呼び出します。



基本クラスに加えて、フィールドのいずれかのコンストラクターが例外をスローできる場合、フィールド初期化子は同様のジョークを再生できます。

class ComposedDisposable : IDisposable

{

public void Dispose() {}



private readonly DisposableA disposableA = new DisposableA();

// , DisposableB ? OOPS!!

private readonly DisposableB disposableB = new DisposableB();

}



* This source code was highlighted with Source Code Highlighter .

この場合、 DisposableBクラスのコンストラクターが、 disposableBフィールドの初期化時に例外をスローすると 、それをキャッチして、既にキャプチャーしたリソースを解放することはできません。 C ++には、初期化リストで発生した例外をキャッチするようなものがありますが（ 例外とメンバーの初期化を参照）、C＃にはそのような可能性はないため、この状況から抜け出す方法は1つしかありません。



これまでのすべてのケースに関して、例外の基本的な保証の提供は開発者に完全に委ねられています。C＃はこれらの目的のための「砂糖」を提供しないからです。 残っているのは、サブオブジェクトを正しい順序で 作成し、コンストラクターの最後に使い捨てフィールドを作成するか、その作成をtry / catchブロックでラップして、例外が発生した場合にすべてのリソースをクリアすることです。

例外の厳密な保証の例。 オブジェクト初期化子およびコレクション初期化子

上記の例外の基本的な保証の違反の例は、それらはそれほどフェッチされていませんが、それほど一般的ではありません。 また、複数の管理対象リソースを含むオブジェクトを作成する場合、C＃言語コンパイラーが役に立たない場合は、オブジェクトやコレクションを作成するときなど、他のいくつかの場合に役立ちます。



オブジェクトおよびコレクションの初期化子（オブジェクト初期化子およびコレクション初期化子）は、オブジェクトの作成と初期化、またはコレクションに要素のリストを設定する原子性を保証します。 次の例を見てみましょう。

class Person

{

public string FirstName { get ; set ; }

public string LastName { get ; set ; }

public int Age { get ; set ; }

}



var person = new Person

{

FirstName = "Bill" ,

LastName = "Gates" ,

Age = 55,

};



* This source code was highlighted with Source Code Highlighter .

一見、以下の構文糖衣のように思えるかもしれません。

var person = new Person();

person.FirstName = "Bill" ;

person.LastName = "Gates" ;

person.Age = 55;



* This source code was highlighted with Source Code Highlighter .

ただし、実際には、オブジェクト初期化子が呼び出されると、一時変数が作成され、この特定の変数のプロパティが変更されてから、新しいオブジェクトに割り当てられます 。

var tmpPerson = new Person();

tmpPerson.FirstName = "Bill" ;

tmpPerson.LastName = "Gates" ;

tmpPerson.Age = 55;

var person = tmpPerson;



* This source code was highlighted with Source Code Highlighter .

これにより、オブジェクトを作成するプロセスの原子性と、セッターの1つによって例外が発生した場合に部分的に初期化されたオブジェクトを使用できなくなります。 同様の原則は、コレクションの初期化子にあります。オブジェクトが一時コレクションに追加され、それが書き込まれた後にのみ、一時変数が新しいオブジェクトに割り当てられます。



これらの2つの概念の根底にある原則は、ネイティブコードでの例外の厳密な保証の独自の実装で簡単に使用できます。 これを行うには、特定の一時変数でオブジェクトの内部状態のすべての変更を実行するだけで十分であり、完了後にのみ実際の状態がアトミックに変更されます。

おわりに

例外を正しく処理することは簡単なことではなく、いくつかの例が示しているように、例外の基本的な保証さえ難しい場合があります。 ただし、そのような保証を提供することは、アプリケーション全体の薄い層でリソースを塗りつぶすよりも、1か所でリソースを操作する複雑さを隠す方がはるかに簡単であるため、アプリケーションの開発に不可欠な条件です。 10年前にScott Meyersによって策定された黄金のルールは今でも有効です。 正しく使いやすく、間違って使いにくいクラスを作成し 、例外の保証が明らかに重要な役割を果たします。



これらの保証の実際の適用について話す場合、覚えておくべきいくつかのポイントがあります。 まず、基本的な例外保証を満たさないコードは正しくありません。 それに基づいて、使用または変更されたときに状態が壊れないアプリケーションを作成することは不可能です（*****）。 第二に、偏執狂にならず、最大限の保証を求めます。 非同期例外が存在するため、例外がないことを100％保証することはほとんど不可能ですが、厳密な保証を実装することでさえ、多くの場合、不当に高価になる可能性があります。



結論として、次のように言えます。 例外の安全性の保証は万能薬ではなく、信頼できるアプリケーションを構築するための優れた基盤です 。



----------------------



（*）実際には、1つの単純な理由のために「ホットな」議論はありませんでした。例外を処理せずに.Netプラットフォームでプログラミングすることはできません。 このような議論は、特に低レベルのプログラミングに関しては、C ++言語などに関連しています。



（**）一般に、不変保存を常に必要とする人はいません。 通常、 openメソッドの呼び出しの不変の「前」と「後」が必要ですが、作業の「一部」のみを実行する閉じたメソッドの呼び出し後に保存する必要はありません。



（***）C＃のようなより洗練された言語は、古いC ++のようなことをしないかもしれないことは非常に面白いように思えるかもしれませんが、実際はそうです。 例として、前述のコードをC＃からC ++に書き換えましょう。

class Resource1

{

public :

Resource1()

{

// , -

//

}

~Resource1()

{

//

}

};



class Resource2

{

public :

Resource2()

{

// resource1_

throw std::exception( "Yahoo!" );

}

private :

Resource1 resource1_;

};





// - Resource2

Resource2 resource2;



* This source code was highlighted with Source Code Highlighter .

C ++で前述したように（C＃とは異なり）、クラスコンストラクターで例外がスローされると、既に構築されたフィールド（つまり、サブオブジェクト）のデストラクターが自動的に呼び出されます。 つまり、この場合、 Resource1オブジェクトのデストラクターの呼び出しは自動的に行われ、リソースリークは発生しません。



C＃言語とC ++言語のこのような動作の違いは簡単に説明できます。 C ++では、リソースは動的に割り当てられたメモリを含むすべてのものであり、これがリソース管理ツールがより高いレベルにある理由です。 C＃言語で作業する応用プログラマーは、コンストラクターでリソースをキャプチャーするのではなく、usingブロックでリソースを使用することが非常に多くあります。 そして、もし彼がそのような問題に直面しているなら、彼はコンパイラの助けなしに自分でそれを解決しなければなりません。



ところで、Herb Sutterは彼の記事ですでにこれについて一度話しました： 「C ++、C＃、およびJavaのコンストラクタ例外」 。



（****）すでにこれらのメモでそれを入手しているかもしれませんが、それは非常に重要であり、最後から2番目のメモです。 彼らはしばしばインタビューでそのような例を設定することを好むので、今、私の読者はそれに対する正しい答えを知っています！



（*****） OutOfMemoryExceptionやThreadAbortExceptionなどの「非同期」例外の一貫した発生を保証することはほとんど不可能であるため、この記事で述べられていることはすべて同期例外にのみ適用されます。 ここでの証拠：「 Thread.Abortメソッドの危険性について。 」