在C#中集中处理Debug.Assert和抛出异常的更好方式是什么？

Question

我的大部分方法在函数中都会检查null参数，所以我认为，与其编写

Debug.Assert(x != null, "x should not be null");

if (x == null)
{
    throw new ArgumentNullException("x");
}

无论在哪里，我都会创建一个静态类和静态方法来集中处理它。

然而，这种做法也存在问题，就是如果 Debug.Assert 触发了，那么 VS 将会弹出静态方法，而不是调用该方法的位置，而我希望它弹出的地方应该是调用该方法的位置。

只是好奇是否有更好的方法来处理这种情况，或者一般如何处理这种重复性的工作？

谢谢！

- Khronos

---

为什么需要 if (x == null)？Debug.Assert 不够吗？ - L.B

@L.B 我认为在发布版本中 Debug.Assert 是不可用的。所以他也想在这些版本中得到一个异常。 - yas4891

你的意思是“静态方法”指的是“扩展”方法吗？ - yas4891

我想添加Debug.Assert，这样在调试会话期间，VS会弹出窗口，这样我可以更快地跳入相关的代码(因为异常可能被try/catch块捕获和忽略)。但是在发布构建期间，我仍然需要这个异常，因为Debug.Assert将被剥离。但我猜用户如果需要，可以启用所有异常的断点。 - Khronos

通过静态方法，我指的是有一个专门用于这些类型的实用程序类（例如，检查空值，检查空字符串以及检查其他验证相关内容）。 - Khronos

Answer 1

另一种方法是来自微软研究的数据契约。

- Fischermaen

---

我一直在尝试避免安装除了VS默认安装的东西以外的其他内容。但我肯定会看一下这个的。 - Khronos

Answer 2

一个方法是将所有东西都放在代码中，除了变量的名称，以最小化源代码中的字面内容。

Guard.Check(EGuards.NotNull, "x");

如果你喜欢流畅扩展的话，另一种方法是使用它（我对这个有点犹豫）。

x.MustNotBeNull();

- Aaron Anodide

Answer 3

如果你打算显式地抛出异常，那么断言 x != null 就没有什么意义了。在调试时，你会看到异常，除非你有一些全局异常处理 - 即使如此，你也可以在所有异常上中断，而不仅仅是未捕获的异常。

使用 assert 的时间是在你决定最安全的发布模式代码路径是做一些其他事情而不是抛出异常时，例如从函数中提前返回、将变量初始化为默认值等。

并不是要否认其他答案中提到的实用工具，但在特定情况下，你可能需要仔细考虑是抛出异常还是断言更合适（这不仅适用于参数验证）。

- Nicholas W

---

我想同时使用断言和异常的主要原因是为了在VS调试期间方便地弹出窗口，以防异常被某个try/catch块捕获，但我想你是对的，用户可以启用所有异常的中断。 - Khronos

所有异常中断可能会受到（例如）使用内部异常的库代码的影响，因此调试变得非常痛苦，因为异常不断被抛出。然而，维护重复检查代码也可能很痛苦！ - Rich Tebb

Answer 4

例如，在Sharp-architecture中查看设计契约。

- Sergey K

Answer 5

您可能还想查看描述此处的企业库异常处理块。 其中一个特点是集中式异常处理。如果没有其他选择，它是开源的，因此您可以将其用作自己实现的模式。

- user957902