1. 项目概述为什么异常处理是C#开发的“安全带”干了这么多年C#开发从桌面程序到Web API再到各种后台服务我越来越觉得异常处理Exception Handling就像是程序员给代码系上的“安全带”。平时风平浪静时你感觉不到它的存在甚至觉得它有点碍事。可一旦程序在线上“撞车”——可能是数据库连接突然断了用户上传了一个格式诡异的文件或者第三方接口毫无征兆地挂了——这条“安全带”就成了防止系统彻底崩溃、保住关键数据、甚至维持服务可用的最后一道防线。try-catch块就是这条安全带最核心的锁扣。很多新手甚至一些工作了几年的朋友对try-catch的理解还停留在“把可能报错的代码包起来不让程序红字退出”的层面。这没错但这只是最基础的用法。真正高质量的异常处理关乎到系统的健壮性、可维护性以及最关键的问题排查效率。一个设计良好的异常处理策略能让线上问题在几分钟内定位到根因而糟糕的异常处理比如到处是空的catch块或者把异常生生“吞”掉则会让深夜接到报警的你面对一堆“NullReferenceException”却毫无头绪仿佛在迷宫里打转。所以今天我们不聊那些教科书上的概念就从一个一线开发者的视角掰开揉碎了讲讲try-catch在C#里到底该怎么用有哪些你绝对要避开的“坑”以及如何让它成为你调试和运维的利器而不仅仅是代码里的摆设。2. 异常捕获的核心机制与设计哲学2.1try-catch-finally的基本结构与执行流程try-catch-finally这个三件套结构上看似简单但执行顺序里的门道直接决定了资源管理和异常传播的行为。try { // 1. 尝试执行的代码块 Console.WriteLine(“尝试打开文件...”); var file File.OpenRead(“nonexistent.txt”); // 这里可能会抛出 FileNotFoundException // ... 其他操作 } catch (FileNotFoundException ex) // 2. 捕获特定异常 { // 当且仅当抛出的是 FileNotFoundException 或其派生类时执行这里 Console.WriteLine($“文件没找到: {ex.FileName}”); // 可以选择处理异常或者重新抛出 } catch (IOException ex) // 3. 捕获更通用的异常基类 { // 如果抛出的不是FileNotFoundException但是其他IOException如UnauthorizedAccessException这里会捕获 Console.WriteLine(“IO操作出错: ” ex.Message); } catch (Exception ex) // 4. 兜底的异常捕获最通用的Exception { // 捕获所有未被前面catch块处理的异常 Console.WriteLine($“发生了未知错误: {ex.GetType().Name} - {ex.Message}”); // 通常在这里记录日志然后决定是向上抛出还是优雅降级 } finally { // 5. 无论是否发生异常finally块中的代码都会执行 Console.WriteLine(“清理工作执行中...”); // 这里是释放非托管资源如文件句柄、数据库连接、网络连接的黄金位置 }执行流程的关键点try块程序正常执行流进入这里。一旦其中任何语句抛出异常该块内剩余代码将立即被跳过运行时开始寻找匹配的catch块。catch块匹配catch块从上到下依次检查。异常类型必须与catch声明的类型相同或是其派生类才算匹配。因此捕获顺序必须从最具体派生类到最通用基类。如果把catch (Exception ex)放在第一个后面的所有catch块都将永远无法执行。finally块这是“保证执行”的代码块。无论try块是正常完成还是通过catch块处理或重新抛出了异常甚至是try或catch块里执行了return、break、continue等跳转语句finally块都一定会在控制流离开当前方法前执行。这个特性使其成为资源清理的“不二之选”。注意finally块中应避免包含可能抛出异常的复杂逻辑。如果finally自己也抛出了异常它会覆盖掉之前try或catch块中抛出的异常这可能会让原始错误原因丢失给调试带来巨大困难。2.2 异常类型体系从System.Exception说起C#中所有异常都派生自System.Exception类。理解这个层次结构是写好catch子句的前提。System.Exception所有异常的基类。直接捕获它意味着“捕获一切”要慎用。System.SystemException由CLR公共语言运行时抛出的异常基类通常表示运行时环境问题如OutOfMemoryException、StackOverflowException。程序员通常不应抛出此类异常。System.ApplicationException已过时微软原本设计用于应用程序抛出的异常基类但实践中未被广泛采纳现已不推荐使用。常用派生异常ArgumentNullException参数为null。ArgumentException/ArgumentOutOfRangeException参数无效或越界。InvalidOperationException对象当前状态不允许执行该操作。NotSupportedException调用的方法不被支持。FormatException格式不符合要求如int.Parse(“abc”)。IOException输入输出操作失败文件、网络。FileNotFoundException文件未找到。DirectoryNotFoundException目录未找到。SqlException数据库操作异常需要引用System.Data。HttpRequestExceptionHTTP请求失败常用于Web API调用。设计哲学具体优于笼统在编写catch时一个核心原则是尽可能捕获最具体的异常类型。捕获FileNotFoundException比捕获IOException更具体而捕获IOException又比直接捕获Exception好。这样做有两个巨大好处精准处理你可以针对特定的错误类型采取最恰当的恢复措施。比如文件找不到可以提示用户重新选择如果是权限不足则可以引导用户检查权限设置。避免隐藏Bug如果你一股脑儿用catch (Exception)包住所有代码那么一些本应暴露出来的编程错误如NullReferenceException也会被“吞掉”导致程序在一种不可预知的状态下继续运行后续可能引发更诡异、更难排查的问题。2.3 何时该捕获Catch何时该抛出Throw这是异常处理策略的灵魂所在很多代码的混乱都源于此处的决策失误。应该捕获异常的场景已知可恢复的错误你明确知道某种异常可能发生并且有合理的逻辑可以处理它使程序能继续执行。例如解析用户输入的字符串为数字时捕获FormatException然后提示用户重新输入。在边界处进行包装和记录在组件或层的边界如控制器Action、RPC接口实现、事件处理器入口捕获所有未处理的异常记录详细的上下文日志包括参数、用户信息等然后将一个对用户友好的通用错误信息或一个包装后的业务异常返回给调用方。这防止了敏感的堆栈信息泄露也便于运维排查。清理资源通常与finally块或using语句配合使用确保资源被释放。有时在catch块中也需要进行一些特定的清理。应该抛出或重新抛出异常的场景当前上下文无法处理该错误这是最重要的原则。如果一个方法内部发生的异常该方法不知道该如何合理地恢复或响应那么它就不应该捕获这个异常而应该让它向上层调用栈传播直到某个有足够上下文信息来处理的层。转换异常类型以提供更有意义的抽象在底层库中你可能会捕获一个像SocketException这样的技术性异常然后抛出一个自定义的NetworkUnavailableException业务异常这样上层业务代码就不需要关心底层的套接字细节。添加额外的上下文信息在捕获一个异常后你可以创建一个新的异常将原始异常作为InnerException并添加当前方法的相关信息然后抛出这个新异常。这极大地丰富了错误链方便调试。重新抛出的正确姿势// 错误做法这会使异常的原始调用堆栈丢失堆栈跟踪将从这里重新开始。 catch (Exception ex) { // 错误日志... throw ex; // 不要这样做 } // 正确做法1使用 throw; 关键字这会保留原始的异常对象和完整的堆栈跟踪。 catch (Exception ex) { Log.Error(ex, “操作失败进行资源清理...”); Cleanup(); throw; // 重新抛出原异常堆栈信息完整 } // 正确做法2包装成新异常保留 InnerException。 catch (IOException ioEx) { throw new MyAppDataAccessException(“读取配置文件失败”, ioEx); }3. 高级用法与最佳实践模式3.1 异常过滤器Exception FiltersC# 6.0 后的精准捕获利器异常过滤器when关键字允许你在catch块上附加一个条件。只有条件为真时该catch块才会处理异常否则运行时将继续寻找其他匹配的catch块或向上传播。try { await ProcessRequestAsync(request); } catch (HttpRequestException ex) when (ex.StatusCode System.Net.HttpStatusCode.NotFound) { // 只处理404错误其他HttpRequestException如超时、500错误不会进入这里 Logger.LogWarning(“请求的资源不存在 (404).”); return Result.NotFound(); } catch (HttpRequestException ex) when (ex.StatusCode System.Net.HttpStatusCode.RequestTimeout) { // 单独处理超时 Logger.LogWarning(“请求超时.”); return Result.Timeout(); } catch (HttpRequestException ex) { // 处理其他所有HttpRequestException Logger.LogError(ex, “HTTP请求失败.”); return Result.Error(); }过滤器与条件判断在catch块内的区别// 方式A使用过滤器 (when) catch (Exception ex) when (ex.Message.Contains(“特定关键词”)) { // 只有消息含关键词的异常才会被此块捕获。 // 如果条件不满足异常会继续向外层传播或由其他catch处理。 } // 方式B在catch块内用if判断 catch (Exception ex) { if (ex.Message.Contains(“特定关键词”)) { // 处理特定情况 } else { throw; // 必须手动重新抛出 } }关键区别方式A过滤器在条件不满足时不会被视为已处理该异常异常会继续寻找匹配的处理器。而方式B中无论if条件如何该catch (Exception ex)都已经捕获了异常。如果要在else分支中让异常继续传播必须显式使用throw;否则异常就被“吞”掉了。过滤器让代码更清晰意图更明确也减少了忘记重新抛出的风险。3.2 资源管理与using语句try-finally的语法糖对于实现了IDisposable接口的对象如文件流FileStream、数据库连接SqlConnection、网络流NetworkStream必须及时释放资源。using语句是处理这类资源的首选和最佳模式。// 手动 try-finally 释放 SqlConnection connection null; try { connection new SqlConnection(connectionString); connection.Open(); // 使用 connection 进行操作 } finally { connection?.Dispose(); // 确保无论如何都调用 Dispose } // 使用 using 语句 (等价于上面的代码但更简洁安全) using (var connection new SqlConnection(connectionString)) { connection.Open(); // 使用 connection 进行操作 } // 离开此作用域时connection.Dispose() 会自动被调用即使在块内发生异常。using声明C# 8.0C# 8.0引入了更简洁的using声明对象在其所在作用域结束时自动释放。public void ProcessFile() { using var fileStream File.OpenRead(“data.txt”); using var reader new StreamReader(fileStream); // 使用 reader... var content reader.ReadToEnd(); // ... } // 方法结束时reader 和 fileStream 会自动 Dispose顺序与声明相反先reader后fileStream。核心要点using语句本质上会被编译器翻译成一个try-finally块。它不仅能保证资源释放还能使代码意图“这个对象需要被清理”一目了然。对于任何IDisposable对象优先考虑using。3.3 自定义异常构建清晰的业务错误语义当.NET内置的异常类型不足以清晰表达你的业务逻辑错误时就需要创建自定义异常。创建自定义异常类的准则类名以 “Exception” 结尾。继承自ApplicationException历史原因现不推荐或更常见的、直接继承自Exception。提供至少三个标准构造函数无参、带消息、带消息和内部异常以遵循.NET异常约定。添加必要的额外属性来携带错误上下文信息。[Serializable] // 如果需要在不同应用程序域或网络间传递建议标记为可序列化 public class InsufficientBalanceException : Exception { public decimal CurrentBalance { get; } public decimal RequiredAmount { get; } // 标准构造函数 public InsufficientBalanceException() { } public InsufficientBalanceException(string message) : base(message) { } public InsufficientBalanceException(string message, Exception inner) : base(message, inner) { } // 自定义构造函数携带业务上下文 public InsufficientBalanceException(decimal currentBalance, decimal requiredAmount) : base($“余额不足。当前余额{currentBalance:C} 所需金额{requiredAmount:C}”) { CurrentBalance currentBalance; RequiredAmount requiredAmount; } // 用于序列化的构造函数如果标记了[Serializable] protected InsufficientBalanceException(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) : base(info, context) { CurrentBalance info.GetDecimal(nameof(CurrentBalance)); RequiredAmount info.GetDecimal(nameof(RequiredAmount)); } public override void GetObjectData(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) { base.GetObjectData(info, context); info.AddValue(nameof(CurrentBalance), CurrentBalance); info.AddValue(nameof(RequiredAmount), RequiredAmount); } } // 使用示例 public void Withdraw(decimal amount) { if (amount _balance) { throw new InsufficientBalanceException(_balance, amount); } _balance - amount; }使用自定义异常的好处是调用者可以通过捕获InsufficientBalanceException来明确地处理“余额不足”这个业务错误而不是去解析一个通用的InvalidOperationException的消息字符串。这大大提升了代码的可读性和可维护性。3.4 全局异常处理为应用装上最后的“安全网”对于GUI应用如WPF、WinForms或Web应用如ASP.NET Core你需要一个全局异常处理机制来捕获那些未被任何代码处理的“未处理异常”防止应用程序突然崩溃并给用户一个友好的提示同时记录错误日志用于后续分析。ASP.NET Core 中的全局异常处理在Program.cs或启动配置中使用中间件。// Program.cs app.UseExceptionHandler(appError { appError.Run(async context { context.Response.StatusCode (int)HttpStatusCode.InternalServerError; context.Response.ContentType “application/json”; var contextFeature context.Features.GetIExceptionHandlerFeature(); if (contextFeature ! null) { // 记录异常到日志系统如Serilog, NLog var logger context.RequestServices.GetRequiredServiceILoggerProgram(); logger.LogError(contextFeature.Error, “发生未处理的全局异常.”); // 向客户端返回一个友好的错误响应生产环境不要返回堆栈详情 await context.Response.WriteAsync(new ErrorDetails { StatusCode context.Response.StatusCode, Message “服务器内部错误请稍后再试。” // 生产环境消息 // 开发环境可以包含contextFeature.Error.Message }.ToString()); } }); });WPF/WinForms 应用程序在App.xaml.cs或程序入口点订阅全局事件。// App.xaml.cs public partial class App : Application { protected override void OnStartup(StartupEventArgs e) { base.OnStartup(e); // 处理UI线程未处理异常 this.DispatcherUnhandledException OnDispatcherUnhandledException; // 处理非UI线程未处理异常 AppDomain.CurrentDomain.UnhandledException OnUnhandledException; // 对于Task异步异常 TaskScheduler.UnobservedTaskException OnUnobservedTaskException; } private void OnDispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e) { // 记录日志 e.Exception MessageBox.Show($“发生未预期的错误{e.Exception.Message}”, “错误”, MessageBoxButton.OK, MessageBoxImage.Error); e.Handled true; // 设置为true可阻止应用程序崩溃 // 通常建议在记录日志并提示用户后安全地关闭应用或重启相关模块 // Shutdown(); } }重要提示全局异常处理器是最后的手段。你的主要目标仍然应该是在代码的适当层级如业务逻辑层、数据访问层处理掉所有可预见的异常。全局处理器主要用于记录那些真正“意外”的Bug并优雅地降级。4. 实战中的典型“坑”与避坑指南4.1 “吞掉”异常最隐蔽也最危险的错误这是异常处理中最常见的反模式直接导致问题被掩盖调试如同大海捞针。// 反面教材空洞的catch块 try { var result SomeCriticalOperation(); SaveToDatabase(result); } catch (Exception) { // 什么都没做异常被完全忽略。 // 用户看到操作“成功”但数据根本没保存且无任何日志。 } // 反面教材仅打印到控制台在无控制台的服务器应用中无效 try { ProcessUserUpload(file); } catch (Exception ex) { Console.WriteLine(“出错: ” ex.Message); // 在生产服务器上没人能看到这个控制台。 }避坑指南永远不要使用空的catch块。至少记录日志。记录异常时记录完整的异常对象而不仅仅是ex.Message。ex.ToString()包含了消息、堆栈跟踪和内部异常的所有信息是调试的黄金资料。使用成熟的日志框架如Serilog、NLog它们能结构化地记录异常信息并输出到文件、数据库或日志聚合系统如ELK、Seq。// 正确做法记录日志并决定后续操作 try { await _paymentService.ChargeAsync(order); } catch (PaymentGatewayException ex) // 捕获特定的支付网关异常 { _logger.LogError(ex, “支付网关处理订单 {OrderId} 时失败。网关状态码{StatusCode}”, order.Id, ex.StatusCode); // 可以更新订单状态为“支付失败”并通知用户 order.MarkAsPaymentFailed(); await _orderRepository.UpdateAsync(order); // 不再向上抛出因为业务上已处理 } catch (Exception ex) // 兜底捕获其他未知异常 { _logger.LogCritical(ex, “处理订单 {OrderId} 时发生未知系统错误”, order.Id); // 对于无法处理的系统错误通常应重新抛出让上层或全局处理器处理 throw; }4.2 过度捕获与异常类型滥用另一个极端是滥用catch (Exception)或者在不合适的层级捕获异常。// 反面教材在底层方法捕获过于通用的异常并“处理”掉 public bool TryParseConfig(string path) { try { var json File.ReadAllText(path); _config JsonSerializer.DeserializeConfig(json); return true; } catch (Exception ex) // 这里捕获了所有异常包括Json解析错误、文件格式错误等 { _logger.LogDebug(ex, “读取配置文件失败。”); return false; // 调用方只知道失败了但不知道具体原因 } } // 调用方 if (!TryParseConfig(“config.json”)) { /* 现在该怎么办重试用默认值 */ }避坑指南让异常在调用栈中自然传播直到有足够上下文处理它的地方。上面的例子中TryParseConfig方法不知道调用者希望如何应对文件不存在、文件被锁定、JSON格式错误等不同情况。更好的做法是让这些具体的异常抛出由调用者如应用程序初始化代码来决定是终止启动、使用默认配置还是提示用户。如果确实需要提供一个“尝试”语义的方法可以考虑使用Try...模式并返回一个包含详细错误信息的对象而不是简单地返回bool。public OperationResultConfig TryLoadConfig(string path) { try { var json File.ReadAllText(path); var config JsonSerializer.DeserializeConfig(json); return OperationResultConfig.Success(config); } catch (FileNotFoundException ex) { return OperationResultConfig.Fail(“配置文件未找到”, ex); } catch (JsonException ex) { return OperationResultConfig.Fail(“配置文件格式错误”, ex); } catch (Exception ex) { return OperationResultConfig.Fail(“读取配置文件时发生未知错误”, ex); } }4.3 性能考量异常真的“很慢”吗“异常处理影响性能”是一个常见的说法但需要正确理解。异常的抛出和捕获本身确实比普通的条件判断如if开销要大因为涉及堆栈展开和运行时查找处理程序。但是这绝不意味着你应该为了避免异常而编写晦涩难懂的“错误码”返回式代码。核心原则异常应用于“异常”情况而非正常的控制流。错误用法用抛出和捕获异常来实现像“遍历集合直到找到元素”这样的逻辑。// 非常糟糕的性能和设计 try { foreach (var item in list) { if (item.Id targetId) throw new FoundException(item); } } catch (FoundException ex) { return ex.Item; }正确用法异常用于处理那些不经常发生的、意外的错误条件如网络中断、文件丢失、数据库连接失败、无效的用户输入格式等。性能优化建议先验证后操作对于可预见的错误条件如用户输入验证、参数检查优先使用条件语句if进行检查并返回明确的错误信息而不是等操作失败后靠异常来处理。这被称为“防御性编程”。// 好先检查 public decimal CalculateDiscount(Order order) { if (order null) throw new ArgumentNullException(nameof(order)); if (order.Items.Count 0) return 0m; // 正常逻辑不是异常 // ... 计算逻辑 }对于高频、可预见的“错误”路径考虑使用TryParse模式.NET框架本身提供了很多这样的方法如int.TryParse、Dictionary.TryGetValue。它们通过out参数返回结果和布尔值来表示成功与否避免了异常开销。// 优于 int.Parse 在预期输入可能无效时使用 if (int.TryParse(userInput, out int number)) { // 使用 number } else { // 处理无效输入 }结论不要因为对性能的过度担忧而放弃使用异常。在典型的应用程序中异常处理的开销相对于其带来的代码清晰度和可维护性提升而言通常是微不足道的。将性能优化的重点放在真正的瓶颈上如算法复杂度、不必要的数据库查询、低效的IO操作等。4.4 异步编程async/await中的异常处理在async方法中异常处理有特殊之处因为异常可能被“包裹”在Task或ValueTask对象中。关键规则在async方法中异常在await表达式处被抛出。public async Task ProcessDataAsync() { try { var data await _httpClient.GetStringAsync(“https://api.example.com/data”); // 异常可能在这里抛出 var processed await _processor.ProcessAsync(data); // 另一个可能抛异常的地方 await _repository.SaveAsync(processed); } catch (HttpRequestException ex) // 可以捕获来自 GetStringAsync 的异常 { _logger.LogError(ex, “获取数据失败.”); throw; // 或者进行其他处理 } catch (Exception ex) // 捕获其他所有异常 { _logger.LogError(ex, “处理数据过程中失败.”); throw; } }处理多个并行异步任务的异常当使用Task.WhenAll等待多个任务时如果有多个任务抛出异常它们会被聚合到一个AggregateException中。try { Task task1 DoWork1Async(); Task task2 DoWork2Async(); await Task.WhenAll(task1, task2); // 等待所有任务完成 } catch (AggregateException aex) // 注意在 async 上下文中AggregateException 会被“解包” { // 但实际上在 async/await 模式中运行时通常会将 AggregateException 中的第一个内部异常抛出 // 更常见的做法是分别处理每个任务 } // 更好的做法分别处理 var task1 DoWork1Async(); var task2 DoWork2Async(); try { await Task.WhenAll(task1, task2); } catch { // 检查每个任务的状态 if (task1.IsFaulted) _logger.LogError(task1.Exception, “Task1 failed.”); if (task2.IsFaulted) _logger.LogError(task2.Exception, “Task2 failed.”); throw; // 重新抛出观察到的第一个异常或抛出一个新的聚合异常 }async void方法的异常处理应尽量避免async void方法通常用于事件处理器如按钮点击事件。这类方法抛出的异常会直接触发同步上下文如WPF/WinForms的UI线程的未处理异常事件如果未处理会导致应用程序崩溃。// 危险async void private async void Button_Click(object sender, EventArgs e) { try { await SomeAsyncOperation(); } catch (Exception ex) { // 必须在这里处理所有异常 MessageBox.Show($“操作失败{ex.Message}”); } }最佳实践是除非是事件处理程序否则永远不要使用async void。对于其他情况始终返回Task或TaskT。5. 调试与日志让异常信息成为你的盟友5.1 利用Visual Studio调试器深入异常IDE的调试器是理解异常发生时的程序状态的最强大工具。“异常设置”窗口在VS中通过Debug-Windows-Exception Settings打开。你可以在这里配置调试器在特定异常被抛出时即使被try-catch处理立即中断。这对于追踪那些被“吞掉”或快速被处理的异常非常有用。例如你可以勾选System.NullReferenceException的 “Thrown” 复选框这样一旦任何地方发生空引用调试器就会立刻停在抛出点而不是等到程序崩溃。调用堆栈窗口发生异常中断时“调用堆栈”窗口显示了从当前异常点回溯到程序入口的完整方法调用链。这是定位问题根源的路线图。双击堆栈中的任意一行可以查看该方法的局部变量状态。局部变量/自动窗口查看当前作用域内所有变量的值检查是否有意外的null或错误数据。即时窗口在中断时你可以使用即时窗口执行C#表达式或语句来查询或修改状态帮助你进行假设验证。实操技巧当遇到一个难以复现的线上异常时查看其堆栈跟踪信息。在VS中你可以将堆栈跟踪字符串复制到剪贴板然后通过Edit-Pose Special-Paste JSON/XML/Text as Classes来快速创建一个模拟调用链的测试环境或者直接在代码中搜索相关方法名。5.2 结构化日志记录不仅仅是ex.Message在生产环境中你无法附加调试器。此时详尽的日志就是你的眼睛。不要只记录ex.Message。// 糟糕的日志 _logger.LogError(“保存失败” ex.Message); // 良好的结构化日志 _logger.LogError(ex, “保存用户 {UserId} 的订单 {OrderId} 到数据库失败。连接字符串{ConnectionString}”, userId, orderId, _config.DbConnectionString);为什么ex对象如此重要堆栈跟踪精确指出错误发生在哪个文件、哪一行、哪个方法。内部异常许多异常是包装了底层异常的结果。ex.InnerException属性包含了根本原因。递归记录内部异常直到InnerException为null你就能得到完整的错误链。数据字典一些异常如ArgumentException有一个Data属性可以包含额外的键值对信息。使用像Serilog这样的日志库可以轻松地将异常对象和自定义属性进行结构化记录并输出到JSON格式的文件或日志系统中便于后续使用工具如Seq, ELK进行搜索和分析。5.3 设计可调试的异常消息和错误码当抛出异常时你提供的信息质量直接决定了后续调试的难度。抛出异常时的最佳实践消息清晰、可操作消息应该说明什么操作失败了以及失败的原因如果知道。避免模糊的消息如“操作失败”。// 差 throw new InvalidOperationException(“无效操作。”); // 好 throw new InvalidOperationException($“无法在状态为 ‘{_currentState}’ 时执行 ‘{methodName}’ 操作。期望状态为 ‘Active’。”);包含关键参数值如果异常与参数有关将参数名和无效的值包含在消息中。if (value 0 || value 100) throw new ArgumentOutOfRangeException(nameof(value), value, “百分比值必须在0到100之间。”);考虑使用错误码对于大型系统或需要客户端程序化处理的错误可以定义一套错误码枚举或常量字符串。这在Web API中尤其有用客户端可以根据错误码采取不同的行动。public class ApiException : Exception { public string ErrorCode { get; } public ApiException(string errorCode, string message) : base(message) { ErrorCode errorCode; } } // 抛出 throw new ApiException(“INSUFFICIENT_FUNDS”, “账户余额不足无法完成交易。”);遵循这些原则你的异常处理代码将不再是程序的负担而会成为其健壮性和可维护性的坚实基石。记住好的异常处理的目标不是消灭所有的异常那是不可能的而是确保当异常发生时系统能以可控、可观测的方式做出反应并为快速定位和修复问题提供所有必要的信息。
1. 项目概述为什么异常处理是C#开发的“安全带”干了这么多年C#开发从桌面程序到Web API再到各种后台服务我越来越觉得异常处理Exception Handling就像是程序员给代码系上的“安全带”。平时风平浪静时你感觉不到它的存在甚至觉得它有点碍事。可一旦程序在线上“撞车”——可能是数据库连接突然断了用户上传了一个格式诡异的文件或者第三方接口毫无征兆地挂了——这条“安全带”就成了防止系统彻底崩溃、保住关键数据、甚至维持服务可用的最后一道防线。try-catch块就是这条安全带最核心的锁扣。很多新手甚至一些工作了几年的朋友对try-catch的理解还停留在“把可能报错的代码包起来不让程序红字退出”的层面。这没错但这只是最基础的用法。真正高质量的异常处理关乎到系统的健壮性、可维护性以及最关键的问题排查效率。一个设计良好的异常处理策略能让线上问题在几分钟内定位到根因而糟糕的异常处理比如到处是空的catch块或者把异常生生“吞”掉则会让深夜接到报警的你面对一堆“NullReferenceException”却毫无头绪仿佛在迷宫里打转。所以今天我们不聊那些教科书上的概念就从一个一线开发者的视角掰开揉碎了讲讲try-catch在C#里到底该怎么用有哪些你绝对要避开的“坑”以及如何让它成为你调试和运维的利器而不仅仅是代码里的摆设。2. 异常捕获的核心机制与设计哲学2.1try-catch-finally的基本结构与执行流程try-catch-finally这个三件套结构上看似简单但执行顺序里的门道直接决定了资源管理和异常传播的行为。try { // 1. 尝试执行的代码块 Console.WriteLine(“尝试打开文件...”); var file File.OpenRead(“nonexistent.txt”); // 这里可能会抛出 FileNotFoundException // ... 其他操作 } catch (FileNotFoundException ex) // 2. 捕获特定异常 { // 当且仅当抛出的是 FileNotFoundException 或其派生类时执行这里 Console.WriteLine($“文件没找到: {ex.FileName}”); // 可以选择处理异常或者重新抛出 } catch (IOException ex) // 3. 捕获更通用的异常基类 { // 如果抛出的不是FileNotFoundException但是其他IOException如UnauthorizedAccessException这里会捕获 Console.WriteLine(“IO操作出错: ” ex.Message); } catch (Exception ex) // 4. 兜底的异常捕获最通用的Exception { // 捕获所有未被前面catch块处理的异常 Console.WriteLine($“发生了未知错误: {ex.GetType().Name} - {ex.Message}”); // 通常在这里记录日志然后决定是向上抛出还是优雅降级 } finally { // 5. 无论是否发生异常finally块中的代码都会执行 Console.WriteLine(“清理工作执行中...”); // 这里是释放非托管资源如文件句柄、数据库连接、网络连接的黄金位置 }执行流程的关键点try块程序正常执行流进入这里。一旦其中任何语句抛出异常该块内剩余代码将立即被跳过运行时开始寻找匹配的catch块。catch块匹配catch块从上到下依次检查。异常类型必须与catch声明的类型相同或是其派生类才算匹配。因此捕获顺序必须从最具体派生类到最通用基类。如果把catch (Exception ex)放在第一个后面的所有catch块都将永远无法执行。finally块这是“保证执行”的代码块。无论try块是正常完成还是通过catch块处理或重新抛出了异常甚至是try或catch块里执行了return、break、continue等跳转语句finally块都一定会在控制流离开当前方法前执行。这个特性使其成为资源清理的“不二之选”。注意finally块中应避免包含可能抛出异常的复杂逻辑。如果finally自己也抛出了异常它会覆盖掉之前try或catch块中抛出的异常这可能会让原始错误原因丢失给调试带来巨大困难。2.2 异常类型体系从System.Exception说起C#中所有异常都派生自System.Exception类。理解这个层次结构是写好catch子句的前提。System.Exception所有异常的基类。直接捕获它意味着“捕获一切”要慎用。System.SystemException由CLR公共语言运行时抛出的异常基类通常表示运行时环境问题如OutOfMemoryException、StackOverflowException。程序员通常不应抛出此类异常。System.ApplicationException已过时微软原本设计用于应用程序抛出的异常基类但实践中未被广泛采纳现已不推荐使用。常用派生异常ArgumentNullException参数为null。ArgumentException/ArgumentOutOfRangeException参数无效或越界。InvalidOperationException对象当前状态不允许执行该操作。NotSupportedException调用的方法不被支持。FormatException格式不符合要求如int.Parse(“abc”)。IOException输入输出操作失败文件、网络。FileNotFoundException文件未找到。DirectoryNotFoundException目录未找到。SqlException数据库操作异常需要引用System.Data。HttpRequestExceptionHTTP请求失败常用于Web API调用。设计哲学具体优于笼统在编写catch时一个核心原则是尽可能捕获最具体的异常类型。捕获FileNotFoundException比捕获IOException更具体而捕获IOException又比直接捕获Exception好。这样做有两个巨大好处精准处理你可以针对特定的错误类型采取最恰当的恢复措施。比如文件找不到可以提示用户重新选择如果是权限不足则可以引导用户检查权限设置。避免隐藏Bug如果你一股脑儿用catch (Exception)包住所有代码那么一些本应暴露出来的编程错误如NullReferenceException也会被“吞掉”导致程序在一种不可预知的状态下继续运行后续可能引发更诡异、更难排查的问题。2.3 何时该捕获Catch何时该抛出Throw这是异常处理策略的灵魂所在很多代码的混乱都源于此处的决策失误。应该捕获异常的场景已知可恢复的错误你明确知道某种异常可能发生并且有合理的逻辑可以处理它使程序能继续执行。例如解析用户输入的字符串为数字时捕获FormatException然后提示用户重新输入。在边界处进行包装和记录在组件或层的边界如控制器Action、RPC接口实现、事件处理器入口捕获所有未处理的异常记录详细的上下文日志包括参数、用户信息等然后将一个对用户友好的通用错误信息或一个包装后的业务异常返回给调用方。这防止了敏感的堆栈信息泄露也便于运维排查。清理资源通常与finally块或using语句配合使用确保资源被释放。有时在catch块中也需要进行一些特定的清理。应该抛出或重新抛出异常的场景当前上下文无法处理该错误这是最重要的原则。如果一个方法内部发生的异常该方法不知道该如何合理地恢复或响应那么它就不应该捕获这个异常而应该让它向上层调用栈传播直到某个有足够上下文信息来处理的层。转换异常类型以提供更有意义的抽象在底层库中你可能会捕获一个像SocketException这样的技术性异常然后抛出一个自定义的NetworkUnavailableException业务异常这样上层业务代码就不需要关心底层的套接字细节。添加额外的上下文信息在捕获一个异常后你可以创建一个新的异常将原始异常作为InnerException并添加当前方法的相关信息然后抛出这个新异常。这极大地丰富了错误链方便调试。重新抛出的正确姿势// 错误做法这会使异常的原始调用堆栈丢失堆栈跟踪将从这里重新开始。 catch (Exception ex) { // 错误日志... throw ex; // 不要这样做 } // 正确做法1使用 throw; 关键字这会保留原始的异常对象和完整的堆栈跟踪。 catch (Exception ex) { Log.Error(ex, “操作失败进行资源清理...”); Cleanup(); throw; // 重新抛出原异常堆栈信息完整 } // 正确做法2包装成新异常保留 InnerException。 catch (IOException ioEx) { throw new MyAppDataAccessException(“读取配置文件失败”, ioEx); }3. 高级用法与最佳实践模式3.1 异常过滤器Exception FiltersC# 6.0 后的精准捕获利器异常过滤器when关键字允许你在catch块上附加一个条件。只有条件为真时该catch块才会处理异常否则运行时将继续寻找其他匹配的catch块或向上传播。try { await ProcessRequestAsync(request); } catch (HttpRequestException ex) when (ex.StatusCode System.Net.HttpStatusCode.NotFound) { // 只处理404错误其他HttpRequestException如超时、500错误不会进入这里 Logger.LogWarning(“请求的资源不存在 (404).”); return Result.NotFound(); } catch (HttpRequestException ex) when (ex.StatusCode System.Net.HttpStatusCode.RequestTimeout) { // 单独处理超时 Logger.LogWarning(“请求超时.”); return Result.Timeout(); } catch (HttpRequestException ex) { // 处理其他所有HttpRequestException Logger.LogError(ex, “HTTP请求失败.”); return Result.Error(); }过滤器与条件判断在catch块内的区别// 方式A使用过滤器 (when) catch (Exception ex) when (ex.Message.Contains(“特定关键词”)) { // 只有消息含关键词的异常才会被此块捕获。 // 如果条件不满足异常会继续向外层传播或由其他catch处理。 } // 方式B在catch块内用if判断 catch (Exception ex) { if (ex.Message.Contains(“特定关键词”)) { // 处理特定情况 } else { throw; // 必须手动重新抛出 } }关键区别方式A过滤器在条件不满足时不会被视为已处理该异常异常会继续寻找匹配的处理器。而方式B中无论if条件如何该catch (Exception ex)都已经捕获了异常。如果要在else分支中让异常继续传播必须显式使用throw;否则异常就被“吞”掉了。过滤器让代码更清晰意图更明确也减少了忘记重新抛出的风险。3.2 资源管理与using语句try-finally的语法糖对于实现了IDisposable接口的对象如文件流FileStream、数据库连接SqlConnection、网络流NetworkStream必须及时释放资源。using语句是处理这类资源的首选和最佳模式。// 手动 try-finally 释放 SqlConnection connection null; try { connection new SqlConnection(connectionString); connection.Open(); // 使用 connection 进行操作 } finally { connection?.Dispose(); // 确保无论如何都调用 Dispose } // 使用 using 语句 (等价于上面的代码但更简洁安全) using (var connection new SqlConnection(connectionString)) { connection.Open(); // 使用 connection 进行操作 } // 离开此作用域时connection.Dispose() 会自动被调用即使在块内发生异常。using声明C# 8.0C# 8.0引入了更简洁的using声明对象在其所在作用域结束时自动释放。public void ProcessFile() { using var fileStream File.OpenRead(“data.txt”); using var reader new StreamReader(fileStream); // 使用 reader... var content reader.ReadToEnd(); // ... } // 方法结束时reader 和 fileStream 会自动 Dispose顺序与声明相反先reader后fileStream。核心要点using语句本质上会被编译器翻译成一个try-finally块。它不仅能保证资源释放还能使代码意图“这个对象需要被清理”一目了然。对于任何IDisposable对象优先考虑using。3.3 自定义异常构建清晰的业务错误语义当.NET内置的异常类型不足以清晰表达你的业务逻辑错误时就需要创建自定义异常。创建自定义异常类的准则类名以 “Exception” 结尾。继承自ApplicationException历史原因现不推荐或更常见的、直接继承自Exception。提供至少三个标准构造函数无参、带消息、带消息和内部异常以遵循.NET异常约定。添加必要的额外属性来携带错误上下文信息。[Serializable] // 如果需要在不同应用程序域或网络间传递建议标记为可序列化 public class InsufficientBalanceException : Exception { public decimal CurrentBalance { get; } public decimal RequiredAmount { get; } // 标准构造函数 public InsufficientBalanceException() { } public InsufficientBalanceException(string message) : base(message) { } public InsufficientBalanceException(string message, Exception inner) : base(message, inner) { } // 自定义构造函数携带业务上下文 public InsufficientBalanceException(decimal currentBalance, decimal requiredAmount) : base($“余额不足。当前余额{currentBalance:C} 所需金额{requiredAmount:C}”) { CurrentBalance currentBalance; RequiredAmount requiredAmount; } // 用于序列化的构造函数如果标记了[Serializable] protected InsufficientBalanceException(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) : base(info, context) { CurrentBalance info.GetDecimal(nameof(CurrentBalance)); RequiredAmount info.GetDecimal(nameof(RequiredAmount)); } public override void GetObjectData(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) { base.GetObjectData(info, context); info.AddValue(nameof(CurrentBalance), CurrentBalance); info.AddValue(nameof(RequiredAmount), RequiredAmount); } } // 使用示例 public void Withdraw(decimal amount) { if (amount _balance) { throw new InsufficientBalanceException(_balance, amount); } _balance - amount; }使用自定义异常的好处是调用者可以通过捕获InsufficientBalanceException来明确地处理“余额不足”这个业务错误而不是去解析一个通用的InvalidOperationException的消息字符串。这大大提升了代码的可读性和可维护性。3.4 全局异常处理为应用装上最后的“安全网”对于GUI应用如WPF、WinForms或Web应用如ASP.NET Core你需要一个全局异常处理机制来捕获那些未被任何代码处理的“未处理异常”防止应用程序突然崩溃并给用户一个友好的提示同时记录错误日志用于后续分析。ASP.NET Core 中的全局异常处理在Program.cs或启动配置中使用中间件。// Program.cs app.UseExceptionHandler(appError { appError.Run(async context { context.Response.StatusCode (int)HttpStatusCode.InternalServerError; context.Response.ContentType “application/json”; var contextFeature context.Features.GetIExceptionHandlerFeature(); if (contextFeature ! null) { // 记录异常到日志系统如Serilog, NLog var logger context.RequestServices.GetRequiredServiceILoggerProgram(); logger.LogError(contextFeature.Error, “发生未处理的全局异常.”); // 向客户端返回一个友好的错误响应生产环境不要返回堆栈详情 await context.Response.WriteAsync(new ErrorDetails { StatusCode context.Response.StatusCode, Message “服务器内部错误请稍后再试。” // 生产环境消息 // 开发环境可以包含contextFeature.Error.Message }.ToString()); } }); });WPF/WinForms 应用程序在App.xaml.cs或程序入口点订阅全局事件。// App.xaml.cs public partial class App : Application { protected override void OnStartup(StartupEventArgs e) { base.OnStartup(e); // 处理UI线程未处理异常 this.DispatcherUnhandledException OnDispatcherUnhandledException; // 处理非UI线程未处理异常 AppDomain.CurrentDomain.UnhandledException OnUnhandledException; // 对于Task异步异常 TaskScheduler.UnobservedTaskException OnUnobservedTaskException; } private void OnDispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e) { // 记录日志 e.Exception MessageBox.Show($“发生未预期的错误{e.Exception.Message}”, “错误”, MessageBoxButton.OK, MessageBoxImage.Error); e.Handled true; // 设置为true可阻止应用程序崩溃 // 通常建议在记录日志并提示用户后安全地关闭应用或重启相关模块 // Shutdown(); } }重要提示全局异常处理器是最后的手段。你的主要目标仍然应该是在代码的适当层级如业务逻辑层、数据访问层处理掉所有可预见的异常。全局处理器主要用于记录那些真正“意外”的Bug并优雅地降级。4. 实战中的典型“坑”与避坑指南4.1 “吞掉”异常最隐蔽也最危险的错误这是异常处理中最常见的反模式直接导致问题被掩盖调试如同大海捞针。// 反面教材空洞的catch块 try { var result SomeCriticalOperation(); SaveToDatabase(result); } catch (Exception) { // 什么都没做异常被完全忽略。 // 用户看到操作“成功”但数据根本没保存且无任何日志。 } // 反面教材仅打印到控制台在无控制台的服务器应用中无效 try { ProcessUserUpload(file); } catch (Exception ex) { Console.WriteLine(“出错: ” ex.Message); // 在生产服务器上没人能看到这个控制台。 }避坑指南永远不要使用空的catch块。至少记录日志。记录异常时记录完整的异常对象而不仅仅是ex.Message。ex.ToString()包含了消息、堆栈跟踪和内部异常的所有信息是调试的黄金资料。使用成熟的日志框架如Serilog、NLog它们能结构化地记录异常信息并输出到文件、数据库或日志聚合系统如ELK、Seq。// 正确做法记录日志并决定后续操作 try { await _paymentService.ChargeAsync(order); } catch (PaymentGatewayException ex) // 捕获特定的支付网关异常 { _logger.LogError(ex, “支付网关处理订单 {OrderId} 时失败。网关状态码{StatusCode}”, order.Id, ex.StatusCode); // 可以更新订单状态为“支付失败”并通知用户 order.MarkAsPaymentFailed(); await _orderRepository.UpdateAsync(order); // 不再向上抛出因为业务上已处理 } catch (Exception ex) // 兜底捕获其他未知异常 { _logger.LogCritical(ex, “处理订单 {OrderId} 时发生未知系统错误”, order.Id); // 对于无法处理的系统错误通常应重新抛出让上层或全局处理器处理 throw; }4.2 过度捕获与异常类型滥用另一个极端是滥用catch (Exception)或者在不合适的层级捕获异常。// 反面教材在底层方法捕获过于通用的异常并“处理”掉 public bool TryParseConfig(string path) { try { var json File.ReadAllText(path); _config JsonSerializer.DeserializeConfig(json); return true; } catch (Exception ex) // 这里捕获了所有异常包括Json解析错误、文件格式错误等 { _logger.LogDebug(ex, “读取配置文件失败。”); return false; // 调用方只知道失败了但不知道具体原因 } } // 调用方 if (!TryParseConfig(“config.json”)) { /* 现在该怎么办重试用默认值 */ }避坑指南让异常在调用栈中自然传播直到有足够上下文处理它的地方。上面的例子中TryParseConfig方法不知道调用者希望如何应对文件不存在、文件被锁定、JSON格式错误等不同情况。更好的做法是让这些具体的异常抛出由调用者如应用程序初始化代码来决定是终止启动、使用默认配置还是提示用户。如果确实需要提供一个“尝试”语义的方法可以考虑使用Try...模式并返回一个包含详细错误信息的对象而不是简单地返回bool。public OperationResultConfig TryLoadConfig(string path) { try { var json File.ReadAllText(path); var config JsonSerializer.DeserializeConfig(json); return OperationResultConfig.Success(config); } catch (FileNotFoundException ex) { return OperationResultConfig.Fail(“配置文件未找到”, ex); } catch (JsonException ex) { return OperationResultConfig.Fail(“配置文件格式错误”, ex); } catch (Exception ex) { return OperationResultConfig.Fail(“读取配置文件时发生未知错误”, ex); } }4.3 性能考量异常真的“很慢”吗“异常处理影响性能”是一个常见的说法但需要正确理解。异常的抛出和捕获本身确实比普通的条件判断如if开销要大因为涉及堆栈展开和运行时查找处理程序。但是这绝不意味着你应该为了避免异常而编写晦涩难懂的“错误码”返回式代码。核心原则异常应用于“异常”情况而非正常的控制流。错误用法用抛出和捕获异常来实现像“遍历集合直到找到元素”这样的逻辑。// 非常糟糕的性能和设计 try { foreach (var item in list) { if (item.Id targetId) throw new FoundException(item); } } catch (FoundException ex) { return ex.Item; }正确用法异常用于处理那些不经常发生的、意外的错误条件如网络中断、文件丢失、数据库连接失败、无效的用户输入格式等。性能优化建议先验证后操作对于可预见的错误条件如用户输入验证、参数检查优先使用条件语句if进行检查并返回明确的错误信息而不是等操作失败后靠异常来处理。这被称为“防御性编程”。// 好先检查 public decimal CalculateDiscount(Order order) { if (order null) throw new ArgumentNullException(nameof(order)); if (order.Items.Count 0) return 0m; // 正常逻辑不是异常 // ... 计算逻辑 }对于高频、可预见的“错误”路径考虑使用TryParse模式.NET框架本身提供了很多这样的方法如int.TryParse、Dictionary.TryGetValue。它们通过out参数返回结果和布尔值来表示成功与否避免了异常开销。// 优于 int.Parse 在预期输入可能无效时使用 if (int.TryParse(userInput, out int number)) { // 使用 number } else { // 处理无效输入 }结论不要因为对性能的过度担忧而放弃使用异常。在典型的应用程序中异常处理的开销相对于其带来的代码清晰度和可维护性提升而言通常是微不足道的。将性能优化的重点放在真正的瓶颈上如算法复杂度、不必要的数据库查询、低效的IO操作等。4.4 异步编程async/await中的异常处理在async方法中异常处理有特殊之处因为异常可能被“包裹”在Task或ValueTask对象中。关键规则在async方法中异常在await表达式处被抛出。public async Task ProcessDataAsync() { try { var data await _httpClient.GetStringAsync(“https://api.example.com/data”); // 异常可能在这里抛出 var processed await _processor.ProcessAsync(data); // 另一个可能抛异常的地方 await _repository.SaveAsync(processed); } catch (HttpRequestException ex) // 可以捕获来自 GetStringAsync 的异常 { _logger.LogError(ex, “获取数据失败.”); throw; // 或者进行其他处理 } catch (Exception ex) // 捕获其他所有异常 { _logger.LogError(ex, “处理数据过程中失败.”); throw; } }处理多个并行异步任务的异常当使用Task.WhenAll等待多个任务时如果有多个任务抛出异常它们会被聚合到一个AggregateException中。try { Task task1 DoWork1Async(); Task task2 DoWork2Async(); await Task.WhenAll(task1, task2); // 等待所有任务完成 } catch (AggregateException aex) // 注意在 async 上下文中AggregateException 会被“解包” { // 但实际上在 async/await 模式中运行时通常会将 AggregateException 中的第一个内部异常抛出 // 更常见的做法是分别处理每个任务 } // 更好的做法分别处理 var task1 DoWork1Async(); var task2 DoWork2Async(); try { await Task.WhenAll(task1, task2); } catch { // 检查每个任务的状态 if (task1.IsFaulted) _logger.LogError(task1.Exception, “Task1 failed.”); if (task2.IsFaulted) _logger.LogError(task2.Exception, “Task2 failed.”); throw; // 重新抛出观察到的第一个异常或抛出一个新的聚合异常 }async void方法的异常处理应尽量避免async void方法通常用于事件处理器如按钮点击事件。这类方法抛出的异常会直接触发同步上下文如WPF/WinForms的UI线程的未处理异常事件如果未处理会导致应用程序崩溃。// 危险async void private async void Button_Click(object sender, EventArgs e) { try { await SomeAsyncOperation(); } catch (Exception ex) { // 必须在这里处理所有异常 MessageBox.Show($“操作失败{ex.Message}”); } }最佳实践是除非是事件处理程序否则永远不要使用async void。对于其他情况始终返回Task或TaskT。5. 调试与日志让异常信息成为你的盟友5.1 利用Visual Studio调试器深入异常IDE的调试器是理解异常发生时的程序状态的最强大工具。“异常设置”窗口在VS中通过Debug-Windows-Exception Settings打开。你可以在这里配置调试器在特定异常被抛出时即使被try-catch处理立即中断。这对于追踪那些被“吞掉”或快速被处理的异常非常有用。例如你可以勾选System.NullReferenceException的 “Thrown” 复选框这样一旦任何地方发生空引用调试器就会立刻停在抛出点而不是等到程序崩溃。调用堆栈窗口发生异常中断时“调用堆栈”窗口显示了从当前异常点回溯到程序入口的完整方法调用链。这是定位问题根源的路线图。双击堆栈中的任意一行可以查看该方法的局部变量状态。局部变量/自动窗口查看当前作用域内所有变量的值检查是否有意外的null或错误数据。即时窗口在中断时你可以使用即时窗口执行C#表达式或语句来查询或修改状态帮助你进行假设验证。实操技巧当遇到一个难以复现的线上异常时查看其堆栈跟踪信息。在VS中你可以将堆栈跟踪字符串复制到剪贴板然后通过Edit-Pose Special-Paste JSON/XML/Text as Classes来快速创建一个模拟调用链的测试环境或者直接在代码中搜索相关方法名。5.2 结构化日志记录不仅仅是ex.Message在生产环境中你无法附加调试器。此时详尽的日志就是你的眼睛。不要只记录ex.Message。// 糟糕的日志 _logger.LogError(“保存失败” ex.Message); // 良好的结构化日志 _logger.LogError(ex, “保存用户 {UserId} 的订单 {OrderId} 到数据库失败。连接字符串{ConnectionString}”, userId, orderId, _config.DbConnectionString);为什么ex对象如此重要堆栈跟踪精确指出错误发生在哪个文件、哪一行、哪个方法。内部异常许多异常是包装了底层异常的结果。ex.InnerException属性包含了根本原因。递归记录内部异常直到InnerException为null你就能得到完整的错误链。数据字典一些异常如ArgumentException有一个Data属性可以包含额外的键值对信息。使用像Serilog这样的日志库可以轻松地将异常对象和自定义属性进行结构化记录并输出到JSON格式的文件或日志系统中便于后续使用工具如Seq, ELK进行搜索和分析。5.3 设计可调试的异常消息和错误码当抛出异常时你提供的信息质量直接决定了后续调试的难度。抛出异常时的最佳实践消息清晰、可操作消息应该说明什么操作失败了以及失败的原因如果知道。避免模糊的消息如“操作失败”。// 差 throw new InvalidOperationException(“无效操作。”); // 好 throw new InvalidOperationException($“无法在状态为 ‘{_currentState}’ 时执行 ‘{methodName}’ 操作。期望状态为 ‘Active’。”);包含关键参数值如果异常与参数有关将参数名和无效的值包含在消息中。if (value 0 || value 100) throw new ArgumentOutOfRangeException(nameof(value), value, “百分比值必须在0到100之间。”);考虑使用错误码对于大型系统或需要客户端程序化处理的错误可以定义一套错误码枚举或常量字符串。这在Web API中尤其有用客户端可以根据错误码采取不同的行动。public class ApiException : Exception { public string ErrorCode { get; } public ApiException(string errorCode, string message) : base(message) { ErrorCode errorCode; } } // 抛出 throw new ApiException(“INSUFFICIENT_FUNDS”, “账户余额不足无法完成交易。”);遵循这些原则你的异常处理代码将不再是程序的负担而会成为其健壮性和可维护性的坚实基石。记住好的异常处理的目标不是消灭所有的异常那是不可能的而是确保当异常发生时系统能以可控、可观测的方式做出反应并为快速定位和修复问题提供所有必要的信息。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
