参考What is the correct way to make a custom .NET Exception serializable?
和Are all .NET Exceptions serializable? ...
为什么我的异常应该是可序列化的？
有人说，如果第三方库定义的自定义异常是不可序列化的，“它可以被认为是一个错误”。为什么？
为什么在这方面异常与其他类不同？
【问题讨论】：
标签： .net exception serializable
因为您的异常可能需要在不同的 AppDomain 之间进行编组，如果它们不能（正确）序列化，您将丢失宝贵的调试信息。与其他类不同，您无法控制是否对异常进行编组——它会。
当我的意思是“你将无法控制”时，我的意思是你创建的类通常具有有限的存在空间，并且存在是众所周知的。如果它是一个返回值并且有人试图在不同的 AppDomain（或在不同的机器上）调用它，他们会得到一个错误，并且可以说“不要那样使用它”。调用者知道他们必须将其转换为可以序列化的类型（通过包装方法调用）。但是，由于如果没有被捕获，异常就会冒泡到最顶端，它们可以超越您甚至不知道的 AppDomain 边界。您在不同 AppDomain 中的 20 级自定义应用程序异常可能是 Main() 报告的异常，并且在此过程中没有任何东西可以将其转换为您的可序列化异常。
【讨论】：
除了 Talljoe 的回答之外，您的异常也可以通过 Web 服务传递，在这种情况下，异常需要可序列化/可反序列化，以便可以将其转换为 XML 并由 Web 服务传输
【讨论】：
我认为所有类的默认值都应该是可序列化的，除非它们包含一个明确不可序列化的类。只是因为一些设计师没有考虑，所以不能转移一个类是很烦人的。
与“Final”相同，默认情况下所有变量都应为“Final”，除非您明确说明它们是“Mutable”。
另外，我不确定拥有一个非私有变量是否有意义。
哦，好吧，需要设计我自己的语言。
但答案是，您不知道如何使用您的异常，并且假定它们能够跨远程调用抛出。
【讨论】：
另一个需要可序列化对象的地方是 Asp.Net Session。 我们将最后一个异常存储在 Session 中，不可序列化的异常需要额外的翻译才能将其详细信息存储为可序列化（将原始异常指定为内部没有帮助）
【讨论】：