所有.NET异常都是可序列化的吗？

是否可以序列化所有.NET异常对象？

1> JaredPar..：

---

是的,不是.正如杰夫和其他人所指出的那样,所有异常类应该并且几乎总是可序列化的.如果您遇到不可序列化的特定异常类,则很可能是一个错误.

但是在考虑可序列化时,您需要考虑直接类和所有类型的成员类型(这是一个递归过程).基类Exception类有一个Data类型为IDictionary 的Data属性.这是有问题的,因为它允许您或任何其他人将任何对象添加到异常中.如果此对象不可序列化,则异常的序列化将失败.

Data属性的默认实现会进行一些基本检查,以确保添加的对象是可序列化的.但它在几个方面存在缺陷

只有顶级检查类型的可序列化,并且只能通过检查Type.IsSerializable(不是100%实体检查)来完成此检查. 

该属性是虚拟的.派生的异常类型可以覆盖并使用执行0检查的Hashtable.

2> Jeff Atwood..：

---

是的,但历史上已经存在(没有双关语意)的例外情况.

换句话说,所有异常都应该是可序列化的,但是第三方代码的一些自定义异常可能不是,具体取决于它们的实现方式.

例如,在.NET 1.0时代,由于代码中的错误,官方Microsoft Oracle数据库提供程序的异常不可序列化.

3> drwatsoncode..：

---

这个问题已经得到了充分的回答,但是对于不熟悉C#或序列化的程序员来说,我认为实际上非常有帮助的是指出,一般来说,异常不是可序列化的!

这可能听起来有点挑衅,但让我解释一下.

确实,所有异常都实现了ISerializable接口,但这仅表明它应该是可序列化的.但是实现接口不会使对象Serializable(在此上下文中暗示Exception可以被序列化和反序列化).

正如其他人所指出的,这个问题最准确的答案是,.Net Framework中的许多但肯定不是所有例外都是可序列化的.但是如果问题是在更广泛的范围内使用术语".Net Exception",例如从System.Exception 派生的Exception ,那么就最佳实践和避免错误而言,更好和更有帮助的答案是我在上面做出的断言,一般情况下,例外不是可序列化的.

原因如下:如前所述,对于一个真正可序列化的异常,它必须具有正确的构造函数ctor(SerializationInfo, StreamingContext),并且必须使用适当的属性进行修饰.重要的是,如果省略这些约束,这些约束都不会导致编译器错误!

这意味着从Exception派生的NO类是Serializable,除非采取这些额外的,可选的(从编译器的角度来看)步骤.

即任何未经干扰/不知情的编码器,如下所示派生出一个新的异常,它刚刚创建了一个不可序列化的异常.

class MyNewException : Exception { }

Visual Studio有一个很棒的"Exception"代码段,可以让您快速生成新的可序列化异常.但即使在这种情况下,也没有什么可以提醒或帮助程序员实际序列化对象属性.例如,即使下面的类具有适当的构造函数和属性,MyNewField如果构造函数和GetObjectData中没有其他代码,则不会序列化该属性.

class MyNewException : Exception 
{
    public MyNewField { get; set; }
}

因此,这里的主要观点是,如果由于某种原因必须依赖正确的异常序列化和反序列化,那么应该完全清楚,当涉及到任何自定义代码或程序集时,无法保证它能够正常工作.此外,由于所需的构造函数通常受到保护,因此您无需轻松验证它是否存在(没有反射).

在我自己的项目我在创建例外"代理"可以从没有被序列化本身例外存储的一些信息(例如,消息等)的一些点.这些可用于序列化某些信息,或者反序列化由没有相应构造函数的Exception写入的数据.

4> Barry Kelly..：

---

System.Exception实现ISerializable,但是如果后代没有使用签名实现正确的重载构造函数,则可能不会反序列化(SerializationInfo,StreamingContext).

---

此外，如果派生的异常未正确调用base.GetObjectData，则该基础异常的信息将不会被序列化，这将在反序列化时导致错误。无论哪种情况（缺少构造函数或序列化失败），序列化都会成功，但是反序列化将引发异常。