c#如何自定义异常_c#自定义异常看这一篇就够了_保姆级教程

C#自定义异常必须继承System.Exception或其子类，否则编译报错CS0155；需实现4个构造函数以支持序列化，推荐加ErrorCode等属性但须正确处理序列化，并遵循命名、注释和轻量原则。

开门见山，先说一个最核心的结论：在C#里创建自定义异常，并不是一个宽泛的“必须继承Exception”的要求。准确来说，它**必须继承System.Exception，或者继承它的任意一个子类**。这是条硬性规定，违反的代价就是编译时直接报错CS0155: Cannot throw an object that does not inherit from 'System.Exception'。

为什么一定要继承 Exception 而不是 ExceptionBase 或其他基类

这背后的原因，得追溯到C#异常机制的底层设计。在CLR（公共语言运行时）层面，它就硬性规定所有能被抛出的对象，其类型必须是System.Exception的派生类。你可以做个简单实验：写一个空类class MyErr { }，然后尝试throw new MyErr();——编译器会立刻拒绝你。

• Exception类是CLR唯一认可的“合法异常根类型”（它本身通过一些机制，确保了异常构造的逻辑是封闭的）。
• 这里有个历史坑点：不推荐继承ApplicationException。这个类早已被微软标记为[Obsolete]，官方文档也明确建议“不要再使用它”。
• 如果你的异常需要体现某种语义分层，更佳实践是继承那些具体的、已有的异常类型，比如ArgumentException或InvalidOperationException，而不是凭空去造一个新的根类。

自定义异常的最小可行写法（带序列化支持）

接下来是关键实操。在.NET Core/.NET 5+的时代，序列化（比如用于跨进程通信、WCF、gRPC场景）依然是绕不开的话题。如果忽略了序列化相关的构造函数，你的异常信息在远程调用或日志捕获时，很可能会丢失。

一个健壮的自定义异常，通常需要实现以下四个构造函数：

• 一个无参构造函数（主要供反序列化机制使用）。
• 一个接收(string message)的构造函数（这是最常用的场景）。
• 一个接收(string message, Exception innerException)的构造函数（用于构建异常链，保留内部异常信息）。
• 一个受保护的(SerializationInfo info, StreamingContext context)构造函数（为了兼容.NET Framework，以及在.NET Core中满足显式序列化的需求）。

来看一个标准示例：

public class InvalidOrderStateException : Exception
{
    public InvalidOrderStateException() { }
    public InvalidOrderStateException(string message) : base(message) { }
    public InvalidOrderStateException(string message, Exception innerException) 
        : base(message, innerException) { }
    protected InvalidOrderStateException(SerializationInfo info, StreamingContext context) 
        : base(info, context) { }
}

要不要加额外属性？什么时候加？

当然，很多时候光有错误信息还不够。为异常添加额外属性（比如ErrorCode、OrderId）非常有意义，但这里头有两点需要特别注意：

• 这些自定义属性必须在所有构造函数中被正确初始化。尤其是在那个反序列化构造函数里，你必须记得从info参数中把值读回来，否则序列化再反序列化之后，属性值就会变成默认值（比如0或者null）。
• 如果附加信息只是用于辅助日志记录或调试，其实更推荐使用Exception.Data这个字典属性。它无需修改异常类的结构，并且会自动参与序列化过程。
• 务必警惕：避免将敏感字段（如用户密码、访问令牌）塞进异常属性。因为异常对象很可能被记录到明文日志，甚至意外暴露给前端。

下面是一个安全地补充了ErrorCode属性的写法示例：

public class PaymentFailedException : Exception
{
    public int ErrorCode { get; }

    public PaymentFailedException(int errorCode, string message) 
        : base(message)
    {
        ErrorCode = errorCode;
    }

    protected PaymentFailedException(SerializationInfo info, StreamingContext context) 
        : base(info, context)
    {
        ErrorCode = info.GetInt32(nameof(ErrorCode));
    }

    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        info.AddValue(nameof(ErrorCode), ErrorCode);
        base.GetObjectData(info, context);
    }
}

别忘了给异常加 XML 注释和 [Serializable]

最后是一些提升工程化水平的细节。特性[Serializable]在.NET Framework中是必须显式添加的；在.NET Core/.NET 5+里虽然不强制，但如果缺少它，会导致GetObjectData方法不会被调用，你的自定义序列化逻辑也就失效了。

• XML注释不只是为了代码“好看”。它会在Visual Studio的智能提示、IntelliSense以及生成的API文档中直接显示，对于团队协作至关重要。
• 异常类的命名应以Exception结尾，这是.NET的命名约定，也是Roslyn Analyzer等静态分析工具的检查项。
• 避免在异常构造函数里执行耗时操作（比如IO读写、网络请求、复杂计算）。异常对象的创建理应轻量、即时。

话说回来，比记住所有构造函数写法更重要的，是理解异常的本质：**异常一旦被抛出，就标志着正常的程序流程已经中断。它的核心职责，是清晰、准确地传达“什么错了、在哪错的、以及为什么错”，而不是去修复问题或触发重试逻辑。** 把握住这个原则，很多设计上的纠结就迎刃而解了。