为了补充上面的正确答案，我发现如果我将自定义属性存储在Exception类的Data集合中，就可以避免这种自定义序列化的事情。

例如:

[Serializable]
public class JsonReadException : Exception
{
    // ...

    public string JsonFilePath
    {
        get { return Data[@"_jsonFilePath"] as string; }
        private set { Data[@"_jsonFilePath"] = value; }
    }

    public string Json
    {
        get { return Data[@"_json"] as string; }
        private set { Data[@"_json"] = value; }
    }

    // ...
}

就性能而言，这可能比Daniel提供的解决方案效率更低，可能只适用于“整型”类型，如字符串和整数等。

尽管如此，这对我来说还是很容易理解的。

为了补充上面的正确答案，我发现如果我将自定义属性存储在Exception类的Data集合中，就可以避免这种自定义序列化的事情。

例如:

[Serializable]
public class JsonReadException : Exception
{
    // ...

    public string JsonFilePath
    {
        get { return Data[@"_jsonFilePath"] as string; }
        private set { Data[@"_jsonFilePath"] = value; }
    }

    public string Json
    {
        get { return Data[@"_json"] as string; }
        private set { Data[@"_json"] = value; }
    }

    // ...
}

就性能而言，这可能比Daniel提供的解决方案效率更低，可能只适用于“整型”类型，如字符串和整数等。

尽管如此，这对我来说还是很容易理解的。

在. net Core中，. net 5.0及以上版本不使用Serializable，因为微软遵循在BinaryFormatter中发现的安全威胁实践。

使用存储在数据集合中的示例

异常已经是可序列化的，但是您需要重写GetObjectData方法来存储变量，并提供一个构造函数，可以在重新水化对象时调用该构造函数。

所以你的例子就是:

[Serializable]
public class MyException : Exception
{
    private readonly string resourceName;
    private readonly IList<string> validationErrors;

    public MyException(string resourceName, IList<string> validationErrors)
    {
        this.resourceName = resourceName;
        this.validationErrors = validationErrors;
    }

    public string ResourceName
    {
        get { return this.resourceName; }
    }

    public IList<string> ValidationErrors
    {
        get { return this.validationErrors; }
    }

    [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter=true)]
    protected MyException(SerializationInfo info, StreamingContext context) : base (info, context)
    {
        this.resourceName = info.GetString("MyException.ResourceName");
        this.validationErrors = info.GetValue("MyException.ValidationErrors", typeof(IList<string>));
    }

    [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter=true)]
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        base.GetObjectData(info, context);

        info.AddValue("MyException.ResourceName", this.ResourceName);

        // Note: if "List<T>" isn't serializable you may need to work out another
        //       method of adding your list, this is just for show...
        info.AddValue("MyException.ValidationErrors", this.ValidationErrors, typeof(IList<string>));
    }

}

实现ISerializable，并遵循执行此操作的常规模式。

您需要用[Serializable]属性标记类，并添加对该接口的支持，还需要添加隐含的构造函数(在该页上有描述，搜索暗示构造函数)。您可以在文本下面的代码中看到它的实现示例。

曾经有一篇来自Eric Gunnerson在MSDN上的优秀文章“脾气暴躁的例外”，但它似乎已经被撤下了。URL是:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp08162001.asp

Aydsman的答案是正确的，更多信息在这里:

http://msdn.microsoft.com/en-us/library/ms229064.aspx

我想不出带有不可序列化成员的Exception的任何用例，但如果您避免尝试在GetObjectData和反序列化构造函数中序列化/反序列化它们，应该是可以的。还要用[NonSerialized]属性标记它们，这更像是文档，因为您自己实现了序列化。