編集の要約なし |
編集の要約なし |
||
| (同じ利用者による、間の5版が非表示) | |||
| 1行目: | 1行目: | ||
== 概要 == | == 概要 == | ||
例外が発生する可能性がある場所では、Try-Catch構文により、その例外をキャッチして適切な処置を施す必要がある。<br> | |||
<br><br> | |||
== 例外クラスの作成 == | |||
==== 例外クラスを作成する前に ==== | |||
例外クラスを作成する前に、注意すべき点が2つある。<br> | |||
* 無闇に例外クラスを作成しない。 | |||
*: .NET Frameworkが提供している例外クラスが使用できる場合は、特別な要件がない限りそれを使用する。 | |||
*: <br> | |||
* 例外クラスをエラー処理以外で使用しない。 | |||
*: 例外は、便利な条件分岐構文ではなく、エラー処理のための機構である。 | |||
*: また、例外を使用せずに済むような状況(例えば、TryParseメソッドが使用できる等)であれば、使用しないに越したことはない。 | |||
*: 例外処理を多用する場合、パフォーマンスに悪影響を及ぼす可能性がある。 | |||
<br> | |||
==== 例外クラスの設計方針 ==== | |||
* 例外クラス名の末尾は、〜Exceptionとする。 | |||
*: このように命名することにより、そのクラスが例外クラスであることが分かる。 | |||
*: <br> | |||
* 全ての例外クラスは、System.Exceptionを継承する。 | |||
*: C#では、System.Exceptionクラスの派生クラスのみをスローすることができる。 | |||
*: <br> | |||
*: Exceptionクラスから派生していないオブジェクトをキャッチすることもできる。 | |||
*: これは、.NET FrameworkのCLRの仕様では、どのようなオブジェクトでもスローすることができるからである。 | |||
*: 他の言語との相互運用することを考慮した結果、C#は任意のオブジェクトをキャッチすることができるようになっている。 | |||
*: <br> | |||
* 例外クラスの継承階層は、できる限り浅くする。 | |||
*: 例外クラスの継承階層を深くすると、基底の例外クラスをキャッチするには、様々なエラーに対処しなければならなくなる。 | |||
*: また、新たな派生クラスを実装するごとに、基底となる例外クラスを捕捉する全ての動作を検証しなければならなくなる。 | |||
*: <br> | |||
* 全ての例外クラスはシリアル化可能であるべきである。 | |||
*: 以下のような場合、例外クラスをシリアル化する必要がある。 | |||
*:* ソフトウェアの実行中にスローされた例外オブジェクトが、ソフトウェアドメインの境界を越える場合 | |||
*:* 例外の内容をログに出力する場合 | |||
*: <br> | |||
*: 上記のようなシーンにおいて、例外クラスを使用しない場合もあるが、 | |||
*: シリアル化の対応は簡単に行うことができるため、対応することにより、例外クラスの堅牢性が増す。 | |||
<br> | |||
==== シリアル化とは ==== | |||
シリアル化とは、オブジェクトをバイトストリームに変換する処理のことである。<br> | |||
オブジェクトの現在の状態をファイルに書き出すような処理を行う。<br> | |||
<br> | |||
シリアル化されたオブジェクトは、テキストファイル等と同様、<br> | |||
ストレージに保存してソフトウェアの起動の時に読み込むこと、ネットワーク上に転送することができる。<br> | |||
ソフトウェアの設定ファイル等でよく使用されている。<br> | |||
<br> | |||
また、シリアル化されたバイトストリームを元のオブジェクトに戻す処理のことを、逆シリアル化と呼ぶ。<br> | |||
[https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/serialization/ シリアル化 (C#) | Microsoft Docs]<br> | |||
<br> | |||
==== 例外クラスの作成 ==== | |||
以下の例では、例外クラスを作成している。<br> | |||
例外クラスは、<code>System.Exception</code>クラスを継承して作成する。<br> | |||
<br> | |||
以下の例のように、4つのコンストラクタは、与えられた引数を基底クラス(<code>System.Exception</code>クラス)のコンストラクタに渡す。<br> | |||
<br> | |||
* 基本の3つのコンストラクタを実装 | |||
*: 3番目のコンストラクタは、例外メッセージと共に、例外の原因となる別の例外への参照を<code>innerException</code>に設定して、 | |||
*: 例外クラスのインスタンスを初期化するためのものである。 | |||
*: <br> | |||
* 例外クラスのシリアル化対応 | |||
*: <code>SerializableAttribute</code>属性と4番目のコンストラクタにより、例外クラスは、ソフトウェアのドメイン境界を越えることができる。 | |||
*: <code>SerializableAttribute</code>属性がある全てのクラスは、フォーマッタを使用してシリアル化が可能になる。 | |||
*: 特に、例外クラスに<code>SerializableAttribute</code>属性がある場合、例外がソフトウェアのドメイン境界を超える時、必要に応じて自動的にシリアル化を行う。 | |||
*: <br> | |||
*: シリアル化されて、別のソフトウェアのドメインからスローされた例外オブジェクトを正しく受け取るためには、元の例外オブジェクトに戻す必要がある。 | |||
*: これを、逆シリアル化と呼ぶ。 | |||
*: これを行うのが、4番目のコンストラクタとなる。 | |||
*: <br> | |||
*: 4番目のコンストラクタは、フォーマッタが呼び出すために存在するため、設計者が明示的に呼び出すことはない。 | |||
*: また、呼び出されることを避けるため、<code>protected</code>修飾子を付加する。(フォーマッタは、アクセス修飾子に関係なく呼び出すことができる) | |||
*: <br> | |||
*: 逆シリアル化コンストラクタが<code>public</code>修飾子の場合、任意のコードから不正なデータを渡して例外クラスのインスタンスを生成できる。 | |||
*: また、例外クラスの継承を禁止する(<code>sealed</code>修飾子を付加する)場合は、逆シリアル化コンストラクタに<code>private</code>修飾子を付加することもできる。 | |||
<syntaxhighlight lang="c#"> | |||
using System; | |||
using System.Runtime.Serialization; | |||
[Serializable()] // クラスがシリアル化可能であることを示す属性 | |||
public class MyException : Exception | |||
{ | |||
public MyException() : base() | |||
{ | |||
} | |||
public MyException(string message) : base(message) | |||
{ | |||
} | |||
public MyException(string message, Exception innerException) : base(message, innerException) | |||
{ | |||
} | |||
// 逆シリアル化コンストラクタ | |||
// このクラスの逆シリアル化するために必須 | |||
// アクセス修飾子をpublicにしないこと(詳細は後述) | |||
protected MyException(SerializationInfo info, StreamingContext context) : base(info, context) | |||
{ | |||
} | |||
} | |||
</syntaxhighlight> | |||
<br><br> | <br><br> | ||