throw语句必须配合try-catch或被调用方处理，否则程序崩溃；async中throw使Task进入Faulted状态；throw;保留原始堆栈，throw ex则丢失；自定义异常须实现三个标准构造函数。
throw 语句必须配合 try-catch 或声明异常才能生效
直接写 throw new ArgumentException("msg") 而不放在 try 块里，或没被上层捕获，程序会崩溃——这不是“没抛出”，而是没处理。C# 的异常机制是“抛出即中断当前执行流”，没人接就终止线程。
- 常见错误：在工具方法里写了
throw，但调用方既没try-catch也没加throws（C# 没 throws 声明，这点和 Java 不同，所以更易忽略） - 正确做法：把可能出错的逻辑封装进有明确契约的方法中，比如
ParseInt(string input)内部校验空值后抛ArgumentNullException，让调用方知道“这个参数不能为 null” - 不要用异常代替流程控制：比如用
throw new InvalidOperationException()来跳出循环，这会让堆栈混乱，且性能差一个数量级
自定义异常类要继承 Exception 并提供三个标准构造函数
只写 class MyException : Exception 是不够的。缺少序列化支持、无法跨 AppDomain 传递、调试时看不到原始上下文。.NET 运行时依赖特定构造函数签名做反序列化。
- 必须实现：
public MyException() : base() { } - 必须实现：
public MyException(string message) : base(message) { } - 必须实现：
public MyException(string message, Exception innerException) : base(message, innerException) { } - 可选但推荐：加
[Serializable]特性（尤其在 Remoting 或旧版 WCF 场景） - 避免在自定义异常里放非序列化字段（如
FileStream），否则反序列化失败
async 方法里 throw 会导致 Task 处于 Faulted 状态，不是直接崩掉线程
这是最容易误解的一点：在 async Task 方法里 throw，不会像同步方法那样立刻终止当前线程，而是把异常包装进返回的 Task 对象里，等待 await 时才真正“抛出”。
- 错误写法：
try { await DoWorkAsync(); } catch (IOException) { ... }—— 如果DoWorkAsync内部抛的是OperationCanceledException，这里根本捕不到 - 正确做法：确保
await后的异常能被外层catch捕获；若需区分异常类型，用task.Exception.InnerException手动检查（仅在未 await 且已知 task 状态为Faulted时） - 注意
async void：异常无法被外部捕获，会直接触发AppDomain.UnhandledException，应绝对避免用于非事件处理场景
throw 和 throw ex 的区别决定调试信息是否丢失
写 throw ex; 会清空原始堆栈跟踪，只剩从这一行开始的新堆栈；而 throw;（无参数）会保留原始异常的完整堆栈。线上排查时，后者能准确定位到最初出问题的那行代码。
- 反模式：
catch (Exception ex) { Log(ex); throw ex; }—— 日志有用，但调试线索断了 - 推荐写法：
catch (Exception ex) { Log(ex); throw; } - 如果真要包装异常，用
throw new CustomException("context", ex);，把原异常作为 innerException 传入 - VS 调试器里看“Exception Settings”窗口，勾选“Common Language Runtime Exceptions”可捕获所有未处理异常，包括被
throw ex隐藏过的
实际项目里最常被忽略的，是异常语义和 HTTP 状态码、API 返回结构之间的映射。比如 Web API 中把 ValidationException 直接抛出，却不转成 400 Bad Request 响应，前端只能看到 500 和一串堆栈——这已经不是 C# 语法问题，而是契约设计问题。
