所有.NETexception都是可序列化的吗？
是否可以序列化所有.NETexception对象？
是的，不是。 正如Jeff和其他人所指出的那样，所有exception类应该并且几乎总是可序列化的。 如果您遇到不可序列化的特定exception类，则很可能是一个错误。
但是在考虑可序列化时，您需要考虑直接类和所有类型的成员（这是一个递归过程）。 基本Exception类有一个Data类型为IDictionary的Data属性。 这是有问题的，因为它允许您或任何其他人将任何对象添加到exception中。 如果此对象不可序列化，则exception的序列化将失败。
Data属性的默认实现确实进行了一些基本检查，以确保添加的对象是可序列化的。 但它在几个方面存在缺陷
- 只有顶级检查类型的可序列化，并且只能通过检查Type.IsSerializable（不是100％实体检查）来完成此检查。
- 该属性是虚拟的。 派生的exception类型可以覆盖并使用执行0检查的Hashtable。
是的，但历史上已经存在（没有双关语）例外。
换句话说， 所有exception都应该是可序列化的 ，但是第三方代码的一些自定义exception可能不是 ，具体取决于它们的实现方式。
例如，在.NET 1.0时代，由于代码中的错误，官方Microsoft Oracle数据库提供程序的exception不可序列化。
这个问题已经得到了充分的回答，但是对于不熟悉C＃或序列化的程序员来说，我认为实际上非常有用的是指出一般情况下，exception不是可序列化的！
这可能听起来有点挑衅，但让我解释一下。
确实，所有Exceptions都实现了ISerializable接口，但这只表明它应该是可序列化的。 但是实现接口并不会使对象Serializable（在此上下文中暗示Exception可以被序列化和反序列化）。
正如其他人所指出的，这个问题最准确的答案是， .Net框架中的许多但肯定不是所有例外都是可序列化的。 但是如果问题是在更广泛的范围内使用术语“.Net Exception”，例如从System.Exception 派生的Exception，那么就最佳实践和避免错误而言，更好，更有帮助的答案是我在上面做出的断言，一般情况下，例外不是可序列化的。
原因如下：如前所述，对于一个真正可序列化的exception，它必须具有正确的构造函数ctor(SerializationInfo, StreamingContext) ，并且必须使用适当的属性进行修饰。 重要的是，如果省略这些约束，这些约束都不会导致编译器错误！
这意味着从Exception派生的NO类是Serializable，除非采取这些额外的，可选的（从编译器的角度来看）步骤。
即任何未经干扰/未知的编码器，如下所示派生出一个新的exception，它刚刚创建了一个不可序列化的exception。
class MyNewException : Exception { }
Visual Studio有一个很棒的“Exception”代码段，可以让您快速生成新的可序列化exception。 但即使在这种情况下，也没有什么可以提醒或帮助程序员实际序列化对象属性。 例如，即使下面的类具有适当的构造函数和属性，如果构造函数和GetObjectData中没有其他代码， MyNewField属性也不会被序列化。
class MyNewException : Exception { public MyNewField { get; set; } }
因此，这里的主要观点是，如果由于某种原因必须依赖正确的exception序列化和反序列化，那么应该完全清楚，当涉及到任何自定义代码或程序集时，无法保证它能够正常工作。 此外，由于所需的构造函数通常受到保护，因此您无需轻松validation它是否存在（没有reflection）。
在我自己的项目中，我在某些方面创建了exception“代理”，它可以存储来自exception的一些信息（例如消息等），这些exception本身不可序列化。 这些可用于序列化某些信息，或者反序列化由没有相应构造函数的Exception写入的数据。
System.Exception实现ISerializable ，但是如果后代没有使用签名(SerializationInfo,StreamingContext)实现正确的重载构造函数，则后代可能不会反(SerializationInfo,StreamingContext) 。
System.Exception实现了ISerializable ，它是所有exception的基类，所以是的。
请参阅： http ： //msdn.microsoft.com/en-us/library/system.exception.aspx