C#自定义异常必须继承System.Exception或其子类，否则编译报错CS0155；需实现4个构造函数以支持序列化，推荐加ErrorCode等属性但须正确处理序列化，并遵循命名、注释和轻量原则。
在C#开发中，自定义异常是处理特定业务错误的常用手段。但很多开发者存在一个误区：认为只要继承Exception类即可。实际上，C#自定义异常有更严格的规范：**它必须直接继承System.Exception，或者继承其任意一个子类**。这是CLR层面的硬性要求，违反此规则将直接导致编译错误CS0155: Cannot throw an object that does not inherit from 'System.Exception'。
为什么自定义异常必须继承 System.Exception
这源于C#异常处理机制的底层设计。公共语言运行时（CLR）规定，所有可被throw关键字抛出的对象，其类型必须是System.Exception的派生类。你可以通过一个简单测试验证：创建一个空类class MyError { }，然后尝试执行throw new MyError();，编译器会立即阻止这一操作。
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、UserId）能极大提升调试效率。但需注意以下关键点：
- 所有自定义属性必须在**每一个**构造函数中被正确初始化。特别是在反序列化构造函数中，必须从
info参数中读取并还原属性值，否则序列化/反序列化后属性将变为默认值。 - 如果附加信息仅用于辅助日志记录或临时调试，更推荐使用
Exception.Data字典属性。它无需修改异常类结构，且会自动参与序列化过程。 - 安全警告：切勿将敏感信息（如用户密码、API密钥、访问令牌）存入异常属性。异常对象可能被记录到明文日志或意外暴露给客户端，导致安全风险。
以下是一个安全添加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);
}
}
提升自定义异常工程化水平的细节
要编写专业级的自定义异常，还需关注以下实践细节：
[Serializable]特性：在.NET Framework中必须显式添加；在.NET Core/.NET 5+中虽非强制，但若缺失会导致GetObjectData方法不被调用，自定义序列化逻辑失效。- 添加XML注释：这不仅提升代码可读性，更能在Visual Studio智能提示、IntelliSense及生成的API文档中直接显示，对团队协作与代码维护至关重要。
- 命名规范：异常类名应以
Exception结尾，这是.NET命名约定，也是Roslyn Analyzer等代码分析工具的检查项。 - 保持轻量：避免在异常构造函数中执行耗时操作（如文件I/O、网络请求、复杂计算）。异常对象的创建应快速、无副作用。
最后，理解异常的本质比记住所有语法更重要：**异常一旦被抛出，即标志着正常的程序流程已中断。其核心职责是清晰、准确地传达“错误类型、发生位置及根本原因”，而非执行修复或重试逻辑。** 把握这一原则，你的异常设计将更加清晰、有效。
