.net - 例外を常に [シリアル化可能] にする必要があるのはなぜですか? （。ネット）

Question

カスタム .NET 例外をシリアライズ可能にする正しい方法は何ですか? を参照してください。
すべての .NET 例外はシリアル化可能ですか? ...

例外をシリアライズ可能にする必要があるのはなぜですか?
サードパーティのライブラリで定義されたカスタム例外がシリアル化できない場合、「バグと見なすことができる」と誰かが言いました。なんで？

この点で例外が他のクラスと異なるのはなぜですか?

Answer 1

例外は異なるAppDomain間でマーシャリングする必要がある場合があり、それらが（適切に）シリアル化できない場合、貴重なデバッグ情報が失われます。他のクラスとは異なり、例外をマーシャリングするかどうかを制御することはできません。

---

私が「あなたがコントロールできない」という意味は、あなたが作成するクラスは一般に有限の存在空間を持ち、その存在はよく知られているということです。それが戻り値であり、誰かが別のAppDomain（または別のマシン）でそれを呼び出そうとすると、障害が発生し、「そのように使用しないでください」と言うことができます。呼び出し元は、（メソッド呼び出しをラップすることによって）シリアル化できるタイプに変換する必要があることを知っています。ただし、例外がキャッチされない場合は最上部までバブルされるため、例外は、自分が持っていることすら知らなかったAppDomainの境界を超える可能性があります。別のAppDomainの20レベルの深さのカスタムアプリケーション例外は、Main（）で報告された例外である可能性があり、途中でそれをシリアル化可能な例外に変換することはありません。

Answer 2

Talljoe の回答に加えて、Web サービス間でも例外が渡される可能性があります。この場合、例外はシリアライズ可能/デシリアライズ可能である必要があるため、XML に変換して Web サービスによって送信できます。

Answer 3

明示的にシリアル化できないクラスが含まれていない限り、すべてのクラスのデフォルトはシリアル化可能である必要があると思います。一部のデザイナーが考えていなかったという理由だけで、クラスを転送できないのは面倒です。

「Final」と同じことです。「Mutable」であると特に言わない限り、すべての変数はデフォルトで「Final」にする必要があります。

また、プライベートではない変数を持つことに意味があるかどうかもわかりません。

まあ、自分の言語を設計する必要があります。

しかし、答えは、例外がどのように使用されるかがわからず、リモート呼び出しでスローできると想定されているということです。