在C#中创建自定义异常类需继承Exception、命名以“Exception”结尾，并实现四个标准构造函数；应在语义化错误区分、业务逻辑特异性及通用异常不适用时使用；需避免吞异常、提供上下文属性、支持序列化以保障兼容性。
在 C# 中创建自定义异常类是构建健壮、可维护应用程序的重要部分。良好的异常处理不仅能帮助开发者快速定位问题，还能提升代码的可读性和可维护性。直接继承 Exception 类并遵循命名和设计规范，是实现自定义异常的关键。
1. 创建自定义异常类的基本步骤
自定义异常类应以 "Exception" 结尾，这是 .NET 的命名约定，有助于其他开发者识别这是一个异常类型。
public class InvalidUserStateException : Exception
{
public InvalidUserStateException()
{
}
public InvalidUserStateException(string message) : base(message)
{
}
public InvalidUserStateException(string message, Exception innerException) : base(message, innerException)
{
}
protected InvalidUserStateException(System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context) : base(info, context)
{
}}
上面的构造函数覆盖了常见使用场景：无参数、带消息、包含内部异常，以及支持序列化（用于远程调用或持久化）。最后一个构造函数虽然不常手动调用，但在分布式系统中必不可少。
2. 何时使用自定义异常
不要为每种错误都创建新异常。应在以下情况考虑自定义：
- 需要区分特定业务逻辑错误，比如用户状态非法、订单已锁定等
- 希望上层代码能通过 catch 明确捕获这类语义化异常
- 框架或通用异常（如 ArgumentException）无法准确表达错误含义
例如，抛出 InvalidUserStateException 比抛出普通 Exception("用户状态无效") 更清晰，也更容易被测试和处理。
3. 遵循良好的异常处理实践
自定义异常只是起点，合理使用才真正体现价值。
- 避免吞掉异常（空 catch），至少记录日志
- 在适当层级包装并抛出，例如将数据库异常转为更高级别的业务异常
- 提供有意义的错误消息，必要时附带上下文数据（可通过属性扩展）
public class OrderProcessingException : Exception
{
public string OrderId { get; }
public OrderProcessingException(string orderId, string message, Exception inner)
: base($"订单 {orderId}: {message}", inner)
{
OrderId = orderId;
}}
这样上层可以访问 OrderId 属性，便于追踪和展示。
4. 不要忽略序列化支持
如果应用涉及 AppDomain 间通信或需要序列化异常（如通过 WCF 或远程服务），必须实现序列化构造函数。虽然现代开发中较少直接使用，但为了兼容性和完整性，建议始终包含。
若使用 .NET Core/.NET 5+，且确定不会进行二进制序列化，可省略该构造函数，但需团队明确共识。
基本上就这些。创建自定义异常不复杂，关键是用得恰当、命名清晰、结构完整。合理的异常设计让错误处理从“救火”变成“导航”。
