“‘Exception.Exception(SerializationInfo, StreamingContext)’已过时”——实现异常的最佳实践？

Question

我在面向 .NET 8.0 的 C# 项目中编写了一个

Exception

子类，IDE 中的模板自动填充了熟悉的序列化构造函数（采用

SerializationInfo

和

StreamingContext

的构造函数），并且构建现在向我发出警告:

warning SYSLIB0051: 'Exception.Exception(SerializationInfo, StreamingContext)' is obsolete:
'This API supports obsolete formatter-based serialization. It should not be called or
extended by application code.' (https://aka.ms/dotnet-warnings/SYSLIB0051)

这里的最佳实践是什么？包含这个构造函数有问题吗？ .NET 8.0 中是否没有任何情况会调用它？忽略它在技术上就违反了合同，不是吗？

是不是说所有基于格式化程序的序列化现在都被认为已经过时了？或者特定的基于格式化程序的

Exception

对象序列化被认为是过时的？是否因为 Exception 对象使用基于格式化程序的序列化在历史上是 .NET 远程处理，而 .NET 远程处理没有被推进到 .NET Core 或更新的 .NET 框架版本中，因此它是预计没有人会再次使用基于格式化程序的序列化??底线：我们是否不再

不再

创建这个构造函数了？此时编写不通过基于格式化程序的序列化的 Exception 类被认为是可以接受的吗？

Answer 1

BinaryFormatter

及其所有依赖类型在 .NET 8.0 中已过时，并且会引发错误（您也可以在错误消息中提供的

link

中看到）。您仍然可以禁用该错误，但在 .NET 9.0 中，该功能最终将从运行时中删除。 由于构造函数

Exception.Exception(SerializationInfo, StreamingContext)

（仅）用于使用 BinaryFormatter 进行反序列化，因此它也已过时，包括所有派生的构造函数。顺便说一句，这也适用于

GetObjectData(SerializationInfo, StreamingContext)

方法。因此您的假设是正确的：

升级到 .NET 8.0 时，您可以（并且应该）从您拥有的任何自定义异常类型中删除该构造函数

以及 GetObjectData 方法。除非您使用 BinaryFormatter（您不应该再使用它），否则它们永远不会被调用，因此可以安全地删除。如果您正在编写自己的序列化基础设施，则需要以不同的方式序列化/反序列化异常。 我记得在.NET的早期版本中，当反序列化构造函数不存在时，甚至会出现一个警告，但这当然也消失了。