Gushwell's C# Dev Notes

1. シールされた型にプロテクト メンバを宣言しないでください

2. 標準の例外コンストラクタを実装します

3. シリアル化コンストラクタを実装します

4. ISerializable を正しく実装します

5. 破棄できるフィールドは破棄します

6. IDisposable を正しく実装します

7. Dispose メソッドから基本クラスの破棄を呼び出します

メールマガジン「C#プログラミングレッスン」[FxCopに学ぶ編] (No219 - No235)では、
FxCopのルールから解かるC#の正しいコードの書き方についての記事を書きましたが、
そこに取り上げなかったルールをいくつか解説しています。
この番外編は、内容的には中級者以上の方向けの内容になっていると思います。
多くの記事の中に埋もれてしまうのは惜しいので、目次をアップします。
  

Gushwell's C# Programing Pageで、メールマガジン『C#プログラミングレッスン』のバックナンバー「FxCopに学ぶ編」をダウンロードできるようにしました。

  

メールマガジン「C#プログラミングレッスン」では、今、[FxCopに学ぶ編] を連載中です。
そこで取上げようとしたルールで、下書きまでしたのですが、結局メルマガには書かないことにしたルールがいくつかあります。
そのまま捨ててしまうのはもったいないので、ブログに掲載します。

---

■IDisposableの実装（３）■

「CA2215:Dispose メソッドから基本クラスの破棄を呼び出します」
というルールがあるのですが、どのようなコードを書いたらこの FxCopの警告が出るのが試したのですが、警告を出すことができません でした。

ということで、いきなりですが、Disposeパターンを実装したクラスを継承する場合の正しいコードを掲載します。
もちろん、DelivedTypeの中で、破棄すべきフィールドを保持していた場合の コードになります。

public class DelivedType : DisposableType { private bool disposed; protected override void Dispose(bool disposing) { try { if ( !this.disposed ) { if ( disposing ) { // ここでDelivedType独自のマネージドリソースの解放 } // ここでDelivedType独自のアンマネージドリソースの解放 } disposed = true; } finally { base.Dispose(disposing); } } }
Disposeパターンを実装したクラスを継承する場合は、 publicな、Disposeメソッドは 継承元で定義済みですので、改めてここで記述する必要はありません。
上記のように、引数ありのDisposeメソッドをoverrideするだけです。
このメソッドの中で継承元の Dispose(disposing) メソッドを忘れずに呼ぶようにします。

■FxCopのルール
CA2215:Dispose メソッドから基本クラスの破棄を呼び出します

  

メールマガジン「C#プログラミングレッスン」では、今、[FxCopに学ぶ編] を連載中です。
そこで取上げようとしたルールで、下書きまでしたのですが、結局メルマガには書かないことにしたルールがいくつかあります。
そのまま捨ててしまうのはもったいないので、ブログに掲載します。

---

■IDisposableの実装（１）■

public class Sample { private TextReader reader; public Sample() { Stream stream = new FileStream(@"d:\temp.txt", FileMode.Open); reader = new StreamReader(stream); } public void Exec() { Console.WriteLine(reader.ReadLine()); } public void Exec2() { string s; while ( (s = reader.ReadLine()) != null ) Console.WriteLine(s); } }
このコードの問題点はなんでしょうか？

それは、Sampleクラスが IDisposableインターフェースを実装していないこと が問題です。

public class Sample : IDisposable { .. }
とIDisposableを指定する必要があります。なぜIDisposableを実装しないと いけないのでしょうか。
それは、reader フィールドのTextReaderクラスがIDisposableを実装している クラスだからです。
TextReaderが使い終わったら、Dispose()メソッドを呼び出しリソースを解放する必要がありますが、それをど こでもやっていません。
どこでTextReaderクラスのDispose()を呼び出せばよいのでしょうか。Execや、Exec2メソッドの中でしょうか。 そうではありませんよね。
利用者側が、Execを呼び出さなかったら、Disposeはされないままですからね。
こんな時には、Sampleクラスにも、Disposeメソッドを定義し、Sampleクラス を利用する側から、Disposeを呼び出してもらえばいいのです。
それが以下のコードです。

public class Sample : IDisposable { private TextReader reader; public Sample() { Stream stream = new FileStream(@"d:\temp.txt", FileMode.Open); reader = new StreamReader(stream); } public void Exec() { Console.WriteLine(tr.ReadLine()); } public void Exec2() { string s; while ( (s = reader.ReadLine()) != null ) Console.WriteLine(s); } public void Dispose() { reader.Dispose(); } }
使う側が、

using (Sample obj = new Sample()) { ...; }
とすれば、usingブロックを抜ける時に、Sample.Dispose()が呼ばれ、その中 で、TextReader.Disposeが呼ばれます。

これで、めでたしめでたし...
ではありません。実は、このコードはFxCopでは警告が出てしまいます。
この警告を手っ取り早く回避するには、

public sealed class Sample : IDisposable { ... }
と sealed クラスにします。
しかし、sealedにするということは、このクラスから継承させることができな いということです。では継承を許し、かつ、IDisposableを実装するにはどう したら良いのでしょうか？

それは次回に解説します。


■FxCopのルール
CA2213: 破棄できるフィールドは破棄します

  

メールマガジン「C#プログラミングレッスン」では、今、[FxCopに学ぶ編] を連載中です。
そこで取上げようとしたルールで、下書きまでしたのですが、結局メルマガには書かないことにしたルールがいくつかあります。
そのまま捨ててしまうのはもったいないので、ブログに掲載します。

---

■独自例外クラスの書き方（３）■■

MyExceptionに独自のプロパティを追加したとします。

[Serializable] public class MyException : Exception { public string MyAdditionalData { get; set; } public MyException() { } public MyException(string message) : base(message) { } public MyException(string message, Exception innerException) : base(message, innerException) { } protected MyException(SerializationInfo info, StreamingContext context) : base(info, context) { } }
このコードを FxCopに食わせると、GetObjectDataの実装を型 MyException に追加してくださいという警告が出ます。

これは、独自のプロパティを正しくシリアライズするために GetObjectDataメソッドを overrideする必要があることを示しています。
独自のフィールド/プロパティを持つ例外クラスを作成する場合は、GetObjectDataをoverrideする必要があります。

GetObjectDataメソッドを実装した MyExceptionを示します。

[Serializable] public class MyException : Exception { public string MyAdditionalData { get; set; } public MyException() { } public MyException(string message) : base(message) { } public MyException(string message, Exception innerException) : base(message, innerException) { } protected MyException(SerializationInfo info, StreamingContext context) : base(info, context) { MyAdditionalData = info.GetString("MyAdditionalData"); } public override void GetObjectData(SerializationInfo info, StreamingContext context) { base.GetObjectData(info, context); info.AddValue("MyAdditionalData", this.MyAdditionalData); } }
MyException(SerializationInfo info, StreamingContext context) コンストラクタも変更されていいる点に注意してください。
これで、シリアライズ、デシリアライズに対応させることができます。

■FxCopのルール
CA2240: ISerializable を正しく実装します

  

メールマガジン「C#プログラミングレッスン」では、今、[FxCopに学ぶ編] を連載中です。
そこで取上げようとしたルールで、下書きまでしたのですが、結局メルマガには書かないことにしたルールがいくつかあります。
そのまま捨ててしまうのはもったいないので、ブログに掲載します。

---

前回の続きです。

■■独自例外クラスの書き方（２）■■

前回は、

public class MyException : Exception { public MyException() { } public MyException(string message) : base(message) { } public MyException(string message, Exception innerException) : base(message, innerException) { } }
と書きましたが、まだ、コンストラクタが不足しています。

MyException(SerializationInfo, StreamingContext)
というコンストラクタを定義する必要があります。
これがないと、この例外をシリアル化することができません。
例えば、ネットワーク越しにこの例外を伝えたいような場合、このコンストラクタが無いと正しく動作しません。

それには、以下のように修正する必要があります。

[Serializable] public class MyException : Exception { public MyException() { } public MyException(string message) : base(message) { } public MyException(string message, Exception innerException) : base(message, innerException) { } protected MyException(SerializationInfo info, StreamingContext context) : base(info, context) { } }
■FxCopのルール
CA2229: シリアル化コンストラクタを実装します

  

メールマガジン「C#プログラミングレッスン」では、今、[FxCopに学ぶ編] を連載中です。
そこで取上げようとしたルールで、下書きまでしたのですが、結局メルマガには書かないことにしたルールがいくつかあります。
そのまま捨ててしまうのはもったいないので、ブログに掲載します。

---

今回は、例外クラスの書き方のルール

■■独自例外クラスの書き方（１）■■
public class MyException : Exception { public MyException() { } public MyException(string message) : base(message) { } }
の問題点はなんでしょうか。

まずは、ある例外が発生した際に、その例外を このMyExceptionにラップしようとしても、それが出来ない点が問題です。

try { DoSomething(foo); } catch (System.ArgumentNullException ex) { throw new MyException("ほにゃらら", ex); }
というコードが書けません。

throw new MyException("ほにゃらら");
だと、System.ArgumentNullException が発生したという情報を innnerExceptionに設定することができません。

public MyException(string message, Exception innerException) : base(message, innerException) { }
というコンストラクタを定義してやる必要があります。
しかし、これだけではまだ不十分です。それはまた次回に。

■FxCopのルール
CA1032: 標準の例外コンストラクタを実装します

  

メールマガジン「C#プログラミングレッスン」では、今、[FxCopに学ぶ編] を連載中です。
そこで取上げようとしたルールで、下書きまでしたのですが、結局メルマガには書かないことにしたルールがいくつかあります。
そのまま捨ててしまうのはもったいないので、ブログに掲載します。

---

次のコードのおかしな点は？ sealed class SealedClass { protected void Hoge() { Console.WriteLine("Hoge"); } }
protected にするということは、派生クラスで利用できるということですが、シールされているので、ここから派生させることはできません。
つまり、sealed と protectedは相矛盾する指定ですので、シールされた型にプ ロテクト メンバを宣言してはいけません。

これって、コンパイルエラーにしても良いのにね。

■FxCopのルール
CA1047: シールされた型にプロテクト メンバを宣言しないでください