参考使自定义.NET异常可序列化的正确方法是什么？
以及 所有 .NET 异常都是可序列化的吗？ ...
为什么我的异常应该是可序列化的？
有人说，如果第三方库定义的自定义异常不可序列化，“可以将其视为错误”。为什么？
为什么异常在这方面与其他类不同？
因为您的异常可能需要在不同的 AppDomain 之间进行编组，如果它们不能（正确）序列化，您将丢失宝贵的调试信息。与其他类不同，您无法控制您的异常是否会被编组 - 它会。
当我的意思是“你无法控制”时，我的意思是你创建的类通常具有有限的存在空间，并且存在是众所周知的。如果它是一个返回值，并且有人试图在不同的 AppDomain（或不同的机器上）中调用它，他们会得到一个错误，并且只能说“不要那样使用它”。调用者知道他们必须将其转换为可以序列化的类型（通过包装方法调用）。然而，由于异常会冒泡到最顶层，如果没有被捕获，它们可能会超越 AppDomain 边界，您甚至不知道自己有这样的边界。您在不同 AppDomain 中深度 20 层的自定义应用程序异常可能是在 Main() 处报告的异常，并且一路上没有任何内容会将其转换为可序列化的异常。
除了 Talljoe 的回答之外，您的异常也可能跨 Web 服务传递，在这种情况下，异常需要可序列化/反序列化，以便可以将其转换为 XML 并由 Web 服务传输
我认为所有类的默认值都应该是可序列化的，除非它们包含明确不可序列化的类。仅仅因为某些设计师没有考虑到而无法转类，这很烦人。
与“Final”相同，默认情况下所有变量都应为“Final”，除非您特别说明它们是“Mutable”。
另外，我不确定拥有非私有变量是否有意义。
哦，好吧，需要设计我自己的语言。
但答案是，您不知道如何使用您的异常，并且假设它们能够通过远程调用抛出。
我对现有答案有不同意见。默认行为应该是不执行任何操作，除非您需要执行该操作。使异常可序列化并不是简单的一行代码。
我们从来没有需要正确编码可序列化的异常。所以，我们不这样做。不需要更多样板。
另一个需要序列化对象的地方是Asp.Net Session。 我们将最后一个异常存储在会话中，而不是可序列化的异常需要额外的转换才能将其详细信息存储为可序列化（将原始异常指定为内部没有帮助）