74. 抛出异常

上一章我们”接”异常，这章讲”抛”异常。很多时候该由你来喊停：方法收到的参数明显不对、对象处于一个不该出现的状态。这时候主动抛异常，比让程序带着错误数据继续跑要安全得多。

为什么该由你主动抛异常

设想一个 OpenAccount 方法收到负数余额。如果你不拦，程序会”假装”开了一个账户，之后利息、转账都基于这个非法数据运算，错误被稀释到各个角落，最后在某个完全不相干的地方炸出来，谁也猜不到根因。

主动抛异常等于在”错误刚露头”的地方就把它摁住，并附上一句清楚的诊断：“余额不能为负”。好处有三：错误在最近处暴露、调用方无法忽视、排错时直奔源头。一句话——好的异常是给未来的自己留的便签。

用 throw 主动抛异常

throw 后面跟一个异常对象。最常见的几个：ArgumentNullException（参数为空）、ArgumentException（参数不合法）、InvalidOperationException（对象状态不对）。

namespace CSharpDemo;

void Greet(string? name)
{
    if (name is null)
        throw new ArgumentNullException(nameof(name), "名字不能为空");
    Console.WriteLine($"你好，{name}");
}

try
{
    Greet(null);
}
catch (ArgumentNullException ex)
{
    Console.WriteLine($"捕获：{ex.Message}");
}

什么时候该主动抛

不是所有错误都要抛异常，下面几种情况最适合：

1. 公开方法的入参不满足前置条件（比如不允许为 null）。
2. 对象当前状态无法完成这次调用（如没初始化就使用）。
3. 收到一个完全不可能的值，说明调用方用错了。

namespace CSharpDemo;

void SetAge(int age)
{
    if (age < 0 || age > 150)
        throw new ArgumentOutOfRangeException(nameof(age), "年龄必须在 0 到 150 之间");
    Console.WriteLine($"年龄设为 {age}");
}

try
{
    SetAge(200);
}
catch (ArgumentOutOfRangeException ex)
{
    Console.WriteLine(ex.Message);
}

重新抛出：throw; 与 throw ex; 的天壤之别

有时你在 catch 里想”先记个日志，再让上层处理”。这时要用 throw;（不带参数），它能保留原始堆栈信息。千万别写 throw ex;，那会重置堆栈，让调试者看不到真正出错的源头。

namespace CSharpDemo;

void DoWork()
{
    try
    {
        int.Parse("abc");
    }
    catch (FormatException ex)
    {
        Console.WriteLine("已记录日志");
        throw;            // 正确：保留原始堆栈
        // throw ex;      // 错误：堆栈被重置，排查困难
    }
}

try
{
    DoWork();
}
catch (FormatException ex)
{
    Console.WriteLine($"外层捕获，堆栈起点仍在 int.Parse：{ex.StackTrace}");
}

用 innerException 串起因果

如果你要抛一个”新异常”但想保留”原始异常”，把它作为第二个参数传进去，成为内部异常（inner exception）。

namespace CSharpDemo;

try
{
    try
    {
        int.Parse("x");
    }
    catch (FormatException ex)
    {
        throw new InvalidOperationException("初始化失败", ex);
    }
}
catch (InvalidOperationException ex)
{
    Console.WriteLine(ex.Message);
    Console.WriteLine($"根因：{ex.InnerException?.Message}");
}

该抛哪一个标准异常

.NET 提供了一整套语义明确的异常，挑对类型能让调用方一眼懂错在哪：

异常	何时用
ArgumentNullException	参数不该为 null
ArgumentOutOfRangeException	参数超出允许范围
ArgumentException	参数不合法（其他情况）
InvalidOperationException	对象当前状态不支持此调用
NotSupportedException	操作根本不被支持
FormatException	字符串格式无法解析

别吞掉异常

最危险的写法就是”捕获了却什么都不做”，这叫吞异常。错误被静默掩盖，问题会在更远的地方以更诡异的方式爆发。

namespace CSharpDemo;

try
{
    int.Parse("abc");
}
catch (FormatException)
{
    // 千万别只留一个空块：错误被吃掉了
    throw;   // 至少要重新抛出，或记日志后抛出
}

守卫子句：提前返回，代码更平

抛出异常配合”守卫子句（guard clause）“写校验，比层层嵌套的 if-else 清爽得多：不满足前置条件就立刻抛，后面的主逻辑才能平铺直叙。

namespace CSharpDemo;

void Transfer(BankAccount from, BankAccount to, decimal amount)
{
    if (from is null) throw new ArgumentNullException(nameof(from));
    if (to is null) throw new ArgumentNullException(nameof(to));
    if (amount <= 0) throw new ArgumentOutOfRangeException(nameof(amount));

    from.Balance -= amount;   // 校验通过，主逻辑干净利落
    to.Balance += amount;
}

class BankAccount { public decimal Balance; }

异常不是普通的流程控制

有人爱用异常来”跳出循环”或”返回错误码”，这是误用。异常的对象创建、栈展开都有开销，应只留给真正的意外。正常的业务分支用 if 和返回值表达。

throw 也能当表达式（C# 7）

从 C# 7 起，throw 可以出现在表达式位置，比如三元运算符或空合并里，省去写完整的 if 块。

namespace CSharpDemo;

string? name = null;
string finalName = name ?? throw new ArgumentNullException(nameof(name));
Console.WriteLine(finalName);

与”返回错误码”对比

方式	优点	缺点
抛异常	无法被忽略，携带堆栈，调用链自动上冒	有性能开销，不能当普通流程用
返回错误码 / bool	轻量、可控	容易被调用方忽略，错误会悄悄传递

经验：库方法的”非法输入/非法状态”用异常；高频、可预期的业务分支（如”查找不到就返回空”）用返回 null 或 bool 更自然。

常见疑问解答

问：参数校验每个方法都写一遍会不会太啰嗦？ 公共 API 和边界处该写就写，内部小工具方法可适当放宽。也可借助 ArgumentException.ThrowIfNullOrEmpty（.NET 7 引入）等 .NET 内置的辅助方法一行搞定。

问：throw; 和 throw new 同类型异常有区别吗？ 有。throw; 保留原堆栈起点；throw new XxxException(...) 会新建一个异常，堆栈从当前行算起，原始堆栈信息丢失（除非用 InnerException 接住）。能原样重抛就优先 throw;。

问：捕获后可不可以”改造”异常再抛？ 可以，用带 InnerException 的新异常把原始异常包起来，既补充了你的上下文，又不丢根因。这正是 throw new InvalidOperationException("...", ex) 的用途。

最佳实践速记

• 参数/状态不合法就主动抛，别带病运行。
• 重新抛出用 throw;，绝不用 throw ex;。
• 要保留根因用 InnerException 包装。
• 别吞异常，空 catch 是隐患。
• 异常留给”意外”，正常分支用返回值。
• 守卫子句 + 早抛，让主逻辑平铺直叙。

小结

主动 throw 适合参数校验和非法状态；重新抛出务必用 throw; 保留原始堆栈，避免 throw ex; 掩盖真相；需要保留根因时用 innerException。下一章我们更进一步，自定义属于自己业务规则的异常类型。