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