我说老李你说黑1. C#异常处理的核心概念
在C#开发中，异常处理是构建健壮应用程序的基石。异常（Exception）本质上是在程序执行期间发生的意外或异常情况，它会中断正常的指令流。与返回错误码的传统方式不同，异常机制提供了更加结构化的错误处理方式。
C#中的异常都是派生自System.Exception类的对象。这个基类包含几个关键属性：
- Message：描述异常原因的文本
- StackTrace：异常发生时的方法调用堆栈
- InnerException：导致当前异常的底层异常（用于异常链）
常见的异常类型包括：
- NullReferenceException：尝试访问null对象的成员
- ArgumentException：传递给方法的参数无效
- IndexOutOfRangeException：数组索引越界
- InvalidOperationException：对象当前状态不允许的操作
- IOException：I/O操作失败
重要提示：永远不要用异常来控制正常程序流程。异常处理应该只用于真正的异常情况，而不是预期的业务逻辑分支。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. C#异常处理的基本语法结构
C#提供了try-catch-finally结构来处理异常，这是异常处理的核心语法。基本形式如下：
csharp复制try
{
// 可能抛出异常的代码
}
catch (SpecificExceptionType ex)
{
// 处理特定类型的异常
}
catch (AnotherExceptionType ex)
{
// 处理另一种类型的异常
}
finally
{
// 无论是否发生异常都会执行的代码
}
2.1 try块的作用域
try块应该只包含可能抛出异常的代码，而不是整个方法体。过度使用大try块会降低代码可读性，并可能意外捕获不应该处理的异常。好的做法是将try块限制在真正可能抛出异常的几行代码上。
2.2 catch块的匹配顺序
catch块是按照从上到下的顺序检查的，所以应该先捕获最具体的异常类型，最后捕获更一般的异常类型。例如：
csharp复制try
{
// 代码
}
catch (FileNotFoundException ex)
{
// 先处理具体的文件未找到异常
}
catch (IOException ex)
{
// 然后处理更一般的IO异常
}
catch (Exception ex)
{
// 最后处理最一般的异常
}
2.3 finally块的确定性执行
finally块中的代码无论是否发生异常都会执行，这使得它成为释放资源（如文件句柄、数据库连接等）的理想位置。即使在try或catch块中有return语句，finally块也会在方法返回前执行。
3. 创建自定义异常
虽然.NET提供了丰富的内置异常类型，但在某些情况下创建自定义异常类型是有意义的。自定义异常应该继承自ApplicationException或更合适的基类异常。
创建自定义异常的最佳实践：
- 类名以"Exception"结尾
- 实现所有标准异常构造函数
- 提供额外的属性和方法以携带更多错误信息
- 确保异常是可序列化的（用于跨应用程序域或进程边界）
示例：
csharp复制[Serializable]
public class InvalidOrderException : ApplicationException
{
public int OrderId { get; }
public InvalidOrderException(int orderId)
: base($"Order {orderId} is invalid")
{
OrderId = orderId;
}
protected InvalidOrderException(SerializationInfo info, StreamingContext context)
: base(info, context)
{
OrderId = info.GetInt32(nameof(OrderId));
}
public override void GetObjectData(SerializationInfo info, StreamingContext context)
{
base.GetObjectData(info, context);
info.AddValue(nameof(OrderId), OrderId);
}
}
4. 异常处理的高级技巧
4.1 异常过滤器（C# 6.0+）
C# 6.0引入了异常过滤器，允许在catch块中使用when子句来指定额外的条件：
csharp复制try
{
// 代码
}
catch (HttpRequestException ex) when (ex.StatusCode == HttpStatusCode.NotFound)
{
// 只处理404 Not Found的HTTP异常
}
异常过滤器的优势在于：
- 不会展开堆栈（stack unwinding），保留了原始调用堆栈
- 可以基于异常属性进行更精细的控制
- 可以记录异常而不实际处理它
4.2 全局异常处理
对于未捕获的异常，可以设置全局异常处理器：
csharp复制// 对于UI应用程序
Application.ThreadException += (s, e) => HandleUnhandledException(e.Exception);
// 对于所有应用程序
AppDomain.CurrentDomain.UnhandledException += (s, e) =>
HandleUnhandledException(e.ExceptionObject as Exception);
注意：全局异常处理器应该只用于记录错误和优雅地关闭应用程序，而不是尝试恢复执行。
4.3 异步代码中的异常处理
async/await模式改变了异常处理的方式。在异步方法中抛出的异常会被捕获并存储在返回的Task对象中，直到await该任务时才会重新抛出。
关键点：
- 异步方法中的异常不会立即抛出，而是被"延迟"到任务被await时
- 可以使用try-catch包围await表达式来捕获异常
- 对于未await的任务，异常可能永远不会被观察到
csharp复制async Task DoWorkAsync()
{
try
{
await SomeAsyncOperation();
}
catch (Exception ex)
{
// 处理异步操作中的异常
}
}
5. 异常处理的最佳实践
5.1 异常处理的基本原则
- 只捕获你能处理的异常：不要捕获所有异常(Exception)，除非是在应用程序的最顶层。
- 提供有意义的错误信息：异常消息应该清楚地解释问题以及可能的解决方案。
- 保持异常不变性：一旦创建了异常对象，就不应该修改它的状态。
- 避免空的catch块：至少要记录异常，即使你不打算处理它。
- 考虑异常性能：异常处理比正常流程慢，不应该用于控制常规程序流。
5.2 日志记录策略
良好的异常处理应该包括详细的日志记录：
csharp复制try
{
// 业务逻辑
}
catch (Exception ex)
{
_logger.LogError(ex, "Failed to process order {OrderId}", orderId);
throw; // 重新抛出以保持调用堆栈
}
日志应该包含：
- 异常类型和消息
- 完整的堆栈跟踪
- 相关业务数据（如订单ID、用户ID等）
- 发生时间戳
5.3 资源清理模式
对于需要清理的资源，推荐使用using语句而不是手动try-finally：
csharp复制using (var resource = new DisposableResource())
{
// 使用资源
} // 自动调用Dispose()
对于异步资源，C# 8.0引入了await using：
csharp复制await using (var resource = new AsyncDisposableResource())
{
// 使用资源
} // 自动调用DisposeAsync()
6. 常见异常处理反模式
6.1 过度捕获异常
csharp复制try
{
// 大量代码
}
catch (Exception)
{
// 捕获所有异常而不做任何处理
}
问题：
- 隐藏了真正的错误
- 可能导致应用程序处于不一致状态
- 难以调试和维护
6.2 异常吞没
csharp复制try
{
// 可能失败的代码
}
catch (Exception ex)
{
// 记录但不重新抛出
_logger.LogError(ex);
}
除非你确定异常不会影响程序正确性，否则应该重新抛出异常或转换为更合适的异常类型。
6.3 抛出基类Exception
csharp复制throw new Exception("Something went wrong");
应该总是抛出最具体的异常类型，这样调用者可以针对特定情况进行处理。
6.4 在finally块中抛出异常
csharp复制finally
{
connection.Close(); // 如果Close抛出异常会掩盖原始异常
}
如果在finally块中必须执行可能抛出异常的操作，应该嵌套try-catch：
csharp复制finally
{
try
{
connection.Close();
}
catch (Exception ex)
{
_logger.LogWarning(ex, "Failed to close connection");
}
}
7. 异常处理与设计模式
7.1 空对象模式
对于某些可能返回null的情况，可以考虑使用空对象模式而不是抛出异常：
csharp复制public interface ILogger
{
void Log(string message);
}
public class NullLogger : ILogger
{
public void Log(string message) { /* 什么都不做 */ }
}
// 使用
ILogger logger = GetLogger() ?? new NullLogger();
logger.Log("message");
7.2 特例模式
类似于空对象模式，但为特定情况提供特殊实现：
csharp复制public class UserRepository
{
public User GetUser(int id)
{
// 如果用户不存在，返回特殊用户而不是抛出异常
return _db.Users.Find(id) ?? new GuestUser();
}
}
7.3 策略模式
将异常处理逻辑封装为策略：
csharp复制public interface IExceptionHandler
{
void Handle(Exception ex);
}
public class LoggingExceptionHandler : IExceptionHandler
{
public void Handle(Exception ex) => _logger.LogError(ex);
}
public class RetryExceptionHandler : IExceptionHandler
{
public void Handle(Exception ex) => RetryOperation();
}
8. 性能考虑与优化
8.1 异常与性能
异常处理比正常流程慢，因为：
- 需要创建异常对象
- 需要捕获和展开调用堆栈
- 需要执行异常处理逻辑
性能敏感代码中应该：
- 避免使用异常进行流程控制
- 使用Try模式（如int.TryParse）
- 预检查条件而不是捕获异常
8.2 Try模式实现
Try模式示例：
csharp复制public bool TryParse(string input, out int result)
{
try
{
result = int.Parse(input);
return true;
}
catch (FormatException)
{
result = 0;
return false;
}
}
8.3 异常与多线程
在多线程环境中：
- 线程池线程的未处理异常会导致进程终止
- 使用Task时，未观察到的异常会触发TaskScheduler.UnobservedTaskException
- 总是await异步任务以确保观察到异常
csharp复制// 不好的做法 - 异常可能被忽略
Task.Run(() => { throw new Exception(); });
// 好的做法 - 确保异常被观察到
try
{
await Task.Run(() => { throw new Exception(); });
}
catch (Exception ex)
{
// 处理异常
}
9. 调试与诊断技巧
9.1 异常断点
在Visual Studio中：
- 打开"异常设置"窗口（Debug > Windows > Exception Settings）
- 勾选你想中断的异常类型
- 调试时遇到这些异常会立即中断
9.2 第一机会异常
AppDomain.FirstChanceException事件允许在异常被捕获前观察到它：
csharp复制AppDomain.CurrentDomain.FirstChanceException += (s, e) =>
{
Debug.WriteLine($"First chance: {e.Exception}");
};
9.3 异常堆栈分析
使用System.Diagnostics.StackTrace可以动态分析调用堆栈：
csharp复制try
{
// 代码
}
catch (Exception ex)
{
var stackTrace = new StackTrace(ex, true);
foreach (var frame in stackTrace.GetFrames())
{
Console.WriteLine($"{frame.GetFileName()}:{frame.GetFileLineNumber()}");
}
}
10. 跨边界异常处理
10.1 跨应用程序域
当异常跨越AppDomain边界时：
- 异常必须可序列化
- 原始异常信息可能丢失
- 考虑使用MarshalByRefObject或WCF风格的错误契约
10.2 Web API异常处理
在ASP.NET Core中，使用中间件统一处理异常：
csharp复制public class ExceptionMiddleware
{
public async Task InvokeAsync(HttpContext context)
{
try
{
await _next(context);
}
catch (Exception ex)
{
context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
await context.Response.WriteAsJsonAsync(new { error = ex.Message });
}
}
}
10.3 数据库异常处理
处理数据库异常时：
- 捕获特定的数据库异常类型（如SqlException）
- 处理连接问题、超时、死锁等
- 考虑重试策略
csharp复制try
{
// 数据库操作
}
catch (SqlException ex) when (ex.Number == 1205) // 死锁
{
// 实现重试逻辑
}
11. 测试异常处理代码
11.1 单元测试中的异常断言
使用测试框架的异常断言：
csharp复制[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void TestNullArgument()
{
new MyClass(null); // 应该抛出ArgumentNullException
}
// 或者使用Assert.ThrowsException
[TestMethod]
public void TestNullArgument()
{
Assert.ThrowsException<ArgumentNullException>(() => new MyClass(null));
}
11.2 模拟异常
使用Mock框架模拟异常：
csharp复制var mockService = new Mock<IDataService>();
mockService.Setup(s => s.GetData()).Throws(new InvalidOperationException());
var processor = new DataProcessor(mockService.Object);
Assert.Throws<InvalidOperationException>(() => processor.Process());
11.3 集成测试中的异常
测试整个流程中的异常处理：
- 模拟故障条件（如网络断开）
- 验证错误响应和日志
- 检查系统状态是否一致
12. 文化与实践
12.1 团队异常处理规范
建立团队共识：
- 什么情况下应该抛出异常
- 什么情况下应该捕获异常
- 如何记录异常
- 自定义异常的创建标准
12.2 代码审查关注点
审查异常处理代码时检查：
- 是否捕获了过于宽泛的异常
- 是否正确地重新抛出异常（使用throw而不是throw ex）
- 资源是否被正确释放
- 错误信息是否有用
12.3 异常处理与领域设计
将异常处理融入领域设计：
- 领域异常应该反映业务规则违反
- 基础设施异常应该与技术问题相关
- 应用层协调异常处理和恢复
csharp复制public class Order
{
public void AddItem(Product product, int quantity)
{
if (product == null)
throw new ArgumentNullException(nameof(product));
if (quantity <= 0)
throw new OrderDomainException("Quantity must be positive");
// 业务逻辑
}
}
在实际项目中，我发现异常处理策略应该尽早确定并在团队中达成一致。一个好的做法是在项目初期就建立异常处理指南，包括：
- 哪些情况应该使用异常而不是返回错误码
- 如何创建有意义的异常消息
- 日志记录的标准格式
- 跨层异常转换的策略
记住，异常处理不是事后才考虑的事情，而是应用程序设计的重要组成部分。良好的异常处理可以显著提高应用程序的健壮性和可维护性，同时减少生产环境中的调试时间。