c#中的throw关键字用于抛出异常，中断正常执行流程并交由异常处理器处理。1. 使用throw new exception()可抛出内置或自定义异常，如argumentoutofrangeexception。2. 自定义异常需继承exception类，命名以exception结尾，包含三个标准构造函数，并可携带业务上下文属性，如insufficientfundsexception包含请求金额和余额。3. 自定义异常提升代码语义清晰度、可读性、可维护性和处理精确性，避免仅用exception导致的模糊性。4. 最佳实践包括：遵循命名规范、实现标准构造函数、添加xml注释、必要时支持序列化。5. throw与throw ex有本质区别：throw保留原始堆栈跟踪，适用于日志记录后重新抛出；throw ex会重置堆栈，应避免使用。6. 仅在异常无法恢复或表示合同违规时抛出异常，不应用于常规流程控制。正确使用throw;是确保异常调试信息完整的关键。
c#中的
throw
关键字，说白了，就是你在程序运行过程中，发现“不对劲”的时候，用来大声喊停并指出问题所在的“信号弹”。它会中断当前正常的代码执行流程，然后把控制权交给一个能够处理这个“不对劲”情况的地方——也就是我们常说的异常处理器（
块）。它就像一个紧急按钮，当你遇到一个无法继续的错误或异常状态时，按下它，告诉系统：“嘿，这里出错了，请处理一下！”
解决方案
在C#中抛出异常，无论是内置的还是自定义的，核心都是使用
throw
关键字。最简单直接的方式就是创建一个新的异常实例并抛出它：
public void ProcessOrder(int orderId, decimal amount) { if (amount <= 0) { // 抛出一个内置的ArgumentOutOfRangeException throw new ArgumentOutOfRangeException(nameof(amount), "订单金额必须大于零。"); } // ... 处理订单逻辑 Console.WriteLine($"订单 {orderId}，金额 {amount} 已处理。"); }
但很多时候，内置的异常类型并不能完全表达我们业务逻辑中遇到的具体问题。这时候，自定义异常就显得尤为重要了。创建自定义异常非常简单，你只需要定义一个类，让它继承自
System.Exception
（或者更具体的异常类型，比如
System.applicationException
，尽管现在更推荐直接继承
Exception
）。
一个典型的自定义异常会包含至少三个构造函数：
- 无参数构造函数。
- 接受一个字符串参数的构造函数，用于传递异常消息。
- 接受一个字符串参数和另一个
Exception
参数的构造函数，用于包装内部异常（即“内部异常”或“原因异常”）。
using System; // 自定义异常：当用户余额不足时抛出 public class InsufficientFundsException : Exception { public decimal RequestedAmount { get; } public decimal AvailableBalance { get; } // 无参数构造函数 public InsufficientFundsException() { } // 带消息的构造函数 public InsufficientFundsException(String message) : base(message) { } // 带消息和内部异常的构造函数 public InsufficientFundsException(string message, Exception innerException) : base(message, innerException) { } // 针对特定业务场景的构造函数，可以携带更多上下文信息 public InsufficientFundsException(string message, decimal requestedAmount, decimal availableBalance) : base(message) { RequestedAmount = requestedAmount; AvailableBalance = availableBalance; } } public class AccountService { private decimal _balance = 100.0m; // 假设初始余额 public void Withdraw(decimal amount) { if (amount <= 0) { throw new ArgumentOutOfRangeException(nameof(amount), "提款金额必须大于零。"); } if (_balance < amount) { // 抛出我们自定义的InsufficientFundsException throw new InsufficientFundsException( $"账户余额不足，无法提取 {amount:C}。当前余额：{_balance:C}。", amount, _balance ); } _balance -= amount; Console.WriteLine($"成功提取 {amount:C}。当前余额：{_balance:C}。"); } } // 如何使用和捕获 public class Program { public static void Main(string[] args) { AccountService service = new AccountService(); try { service.Withdraw(150.0m); // 尝试提取超过余额的金额 } catch (InsufficientFundsException ex) { Console.WriteLine($"捕获到自定义异常：{ex.Message}"); Console.WriteLine($"请求金额：{ex.RequestedAmount:C}，可用余额：{ex.AvailableBalance:C}"); // 这里可以做一些特定的处理，比如通知用户充值 } catch (ArgumentOutOfRangeException ex) { Console.WriteLine($"捕获到参数异常：{ex.Message}"); } catch (Exception ex) // 捕获所有其他未预期的异常 { Console.WriteLine($"捕获到未知异常：{ex.Message}"); } try { service.Withdraw(50.0m); // 正常提款 } catch (Exception ex) { Console.WriteLine($"捕获到异常：{ex.Message}"); } } }
为什么我们需要自定义异常，而不是总用
Exception
Exception
？
在我看来，这就像你有一盒螺丝刀，里面既有通用的一字螺丝刀，也有各种型号的十字、梅花、内六角。当然，你总能用一字螺丝刀去“尝试”拧所有螺丝，但结果往往是把螺丝拧花，或者根本拧不动，甚至伤到自己。
总用
Exception
就好比只用一把通用螺丝刀：
- 缺乏精确性： 当你捕获到
Exception
时，你不知道具体是哪里出了问题，是文件没找到？网络断了？还是业务逻辑中的某个特定条件不满足？所有错误都混成一团，导致你无法针对性地处理。
- 代码可读性差： 你的
catch
块里可能要写一大堆
if (ex.Message.Contains("xxx"))这样的判断，这不仅丑陋，而且脆弱，一旦消息字符串变了，你的逻辑就失效了。
- 难以调试： 想象一下，一个复杂的系统抛出了一个
Exception
，日志里只有一句“发生错误”。你得大海捞针去猜测是哪部分代码、什么业务条件导致了这个错误。
- 阻碍特定处理： 如果你不能区分异常类型，就无法为不同类型的错误提供不同的、优雅的恢复或提示机制。比如，余额不足和网络中断的处理方式肯定不一样，但如果都只捕获
Exception
，你就得在内部再做区分。
自定义异常则提供了“专用工具”：
- 语义清晰：
InsufficientFundsException
一眼就能看出是钱不够了，
ProductNotFoundException
就是产品没找到。这让代码的意图非常明确。
- 精确捕获与处理： 你可以编写
catch (InsufficientFundsException ex)
，然后在这个块里专门处理余额不足的情况，比如提示用户充值。而其他类型的异常则由其他
catch
块处理，或者向上层抛出。
- 携带上下文信息： 像我上面示例中那样，自定义异常可以包含额外的属性（如
RequestedAmount
和
AvailableBalance
），这些信息对于理解和处理异常至关重要，是
Exception
本身无法提供的。
- 提高系统健壮性： 通过区分异常类型，你可以构建更具弹性的错误处理策略，让系统在面对不同故障时能做出更智能的响应。这才是真正意义上的“优雅降级”。
所以，自定义异常不仅仅是代码风格问题，它直接关乎到你的程序是否易于理解、易于维护、以及在面对错误时是否足够“聪明”。
自定义异常的最佳实践有哪些？
创建自定义异常并非随意为之，遵循一些约定和实践能让你的异常体系更具C#风格和实用性：
-
命名约定： 你的自定义异常类名应该以
Exception
结尾。这是C#的普遍约定，例如
MyCustomLogicException
，而不是
MyCustomLogicError
。这能让开发者一眼看出它是一个异常类。
-
继承体系： 大多数情况下，直接继承
System.Exception
就足够了。但如果你的异常在语义上更接近某个特定的内置异常（比如它本质上是参数问题，但又想加点自定义信息），你可以考虑继承
ArgumentException
、
InvalidOperationException
等。避免直接继承
System.ApplicationException
，尽管它听起来很适合应用程序级别的异常，但微软的文档和社区实践表明，直接继承
Exception
更为常见和推荐。
-
标准构造函数： 务必实现那三个标准的构造函数：
-
public YourCustomException()
：无参构造函数，用于简单抛出。
-
public YourCustomException(string message)
：接受一个字符串消息，这是最常用的。
-
public YourCustomException(string message, Exception innerException)
：接受消息和一个内部异常。这个非常重要，当你捕获到一个底层异常，但想把它包装成更高级别的业务异常时，就可以用它来保留原始错误的上下文。
-
-
添加业务特定属性： 如果你的异常需要携带额外的上下文信息，就像我们
InsufficientFundsException
中的
RequestedAmount
和
AvailableBalance
，那就大胆地添加只读属性。这些信息对于异常的捕获者来说是金子，能帮助他们更好地理解和处理问题。
-
XML文档注释： 为你的自定义异常类和它的构造函数添加清晰的XML文档注释。这对于使用你代码的其他人（甚至未来的你自己）来说，是理解这个异常何时抛出、代表什么、以及包含哪些信息的关键。
-
序列化支持（可选但推荐）： 如果你的应用程序需要在应用程序域之间传递异常（例如，通过网络服务或跨进程通信），那么你的自定义异常类需要支持序列化。这通常意味着：
-
添加
[Serializable]
特性。
-
实现一个特殊的构造函数：
protected YourCustomException(SerializationInfo info, StreamingContext context)
。
-
重写
GetObjectData
方法。
[Serializable] public class MySerializableException : Exception { // ... 标准构造函数 ... protected MySerializableException(SerializationInfo info, StreamingContext context) : base(info, context) { // 恢复自定义属性 MyCustomProperty = info.GetString("MyCustomProperty"); } public override void GetObjectData(SerializationInfo info, StreamingContext context) { base.GetObjectData(info, context); // 存储自定义属性 info.AddValue("MyCustomProperty", MyCustomProperty); } public string MyCustomProperty { get; } }对于大多数简单的Web API或桌面应用，如果异常只在当前进程内抛出和捕获，这一步可以省略，但了解它很重要。
-
-
何时抛出： 异常应该用于表示“异常”情况，即程序无法正常继续执行的错误状态。不要用异常来做流程控制，比如用它来表示一个用户输入无效（这种情况通常用返回
或
TryParse
模式更好）。异常通常表示一个合同违规、一个不可恢复的错误、或者一个程序无法预料的外部条件。
遵循这些实践，你的自定义异常将成为C#代码中强大且富有表现力的错误处理工具。
throw
throw
和
throw ex
有什么区别？何时使用
throw;
？
这可能是C#异常处理中最容易让人犯错，也最容易导致调试噩梦的地方。简单来说，
throw
和
throw ex
在行为上有着天壤之别，尤其是在涉及到异常的堆栈跟踪信息时。
-
throw ex;
(或者
throw new Exception("..."))： 当你写
throw ex;
时，你实际上是在创建一个“新的”异常抛出点。这意味着，当前的堆栈跟踪信息会被重置，异常的源头看起来就是
throw ex;
这行代码所在的位置，而原始异常发生时的调用堆栈信息则会丢失或被截断。这对于调试来说是个灾难，因为你无法准确追溯到导致问题的最初根源。它会“欺骗”你，让你以为错误发生在你重抛异常的地方，而不是它真正开始的地方。
举个例子：
public void MethodA() { MethodB(); } public void MethodB() { MethodC(); } public void MethodC() { throw new InvalidOperationException("原始错误"); } // 原始错误在这里 public void MethodD() { try { MethodA(); } catch (InvalidOperationException ex) { Console.WriteLine("捕获到异常，但现在我要用 throw ex; 重新抛出它。"); throw ex; // 这里是 MethodD，但异常的堆栈会从这里开始 } } // 当 MethodD 调用时，如果 MethodC 抛出异常，然后 MethodD 的 catch 块里用 throw ex; // 那么最终捕获到的异常堆栈，会显示异常是从 MethodD 的 throw ex; 那行开始的， // 而 MethodA, MethodB, MethodC 的调用信息可能就丢失了。 -
throw;
： 这是在
catch
块内部重新抛出当前捕获到的异常的正确方式。当你使用
throw;
时，它会保留原始异常的所有信息，包括它最初被抛出时的完整堆栈跟踪。这意味着，无论异常经过多少层
catch
块的捕获和重抛，你最终在日志或调试器中看到的堆栈跟踪信息，都将指向异常最初发生的那一行代码。这对于定位和解决问题至关重要。
当你需要在
catch
块中做一些日志记录、清理工作，或者在不完全处理异常的情况下，想让异常继续向上层传播时，
throw;
就是你的不二之选。
public void MethodA() { MethodB(); } public void MethodB() { MethodC(); } public void MethodC() { throw new InvalidOperationException("原始错误"); } // 原始错误在这里 public void MethodD() { try { MethodA(); } catch (InvalidOperationException ex) { Console.WriteLine($"在 MethodD 中捕获到异常：{ex.Message}"); // 这里可以记录日志，或者进行一些资源清理 // Log.Error("发生业务逻辑错误", ex); // 现在，使用 throw; 重新抛出原始异常，保留原始堆栈信息 throw; // 最终捕获到的异常堆栈，会指向 MethodC 中抛出的位置 } }
何时使用
throw;
？
- 日志记录并重新抛出： 这是最常见的场景。你捕获一个异常，记录下它的详细信息（包括完整的堆栈跟踪），然后不完全处理它，而是让它继续向上层传播，以便更高层的代码可以处理或最终导致程序终止。
- 部分处理并重新抛出： 比如，你捕获了一个文件操作异常，你可能想在
catch
块里关闭文件句柄，但仍然希望这个异常能够继续传播，告知调用者文件操作失败。
- 异常转换/包装： 当你捕获一个低级异常（比如
SqlException
），并想把它包装成一个更高级别的业务异常（比如
DataaccessException
）时，你会创建新的业务异常，并将原始异常作为其
InnerException
，然后抛出新的业务异常。但如果你只是想记录并传递原始异常，
throw;
是更好的选择。
总而言之，记住这个黄金法则：如果你想在
catch
块中重新抛出你刚刚捕获到的异常，并且希望保留其原始的堆栈跟踪信息以便于调试，请务必使用
throw;
。 避免使用
throw ex;
，除非你确实有非常特殊且明确的理由（例如，你明确知道你想截断堆栈，但这非常罕见且不推荐）。
评论（已关闭）
评论已关闭