为什么不同时使用 Debug.Assert 和异常抛出

Question

这个 Debug.Assert vs Exception Throwing 已经被打死了。我明白其中的区别。 Assert是程序员错误；外部意外情况除外。我明白了。

但是，在我编写的代码中，我有时使用

AgumentNullException.ThrowIfNull(theParam)

，有时使用

Debug.Assert(theParam != null)

。我敢打赌你们一半人会做第一个，另一半会做第二个:)

那么 - 为什么不两者都使用呢？也许

TestStringArg(string theStringArg)
{
    Debug.Asert(theStringArg != null);
    Debug.Assert(theString != string.Empty);
    ArgmentNullException.ThrowIfNull(theStringArg);
    ArgumentException.ThrowIfNullOrWhiteSpace(theStringArg);
}

Answer 1

抱歉，不，您对

Debug.Assert.System.Diagnostics

和例外情况的解释不正确。

看起来您认为您正在使用

Assert

作为在作为第一个

Assert

参数传递的某些运行时条件上抛出异常的不同形式。但这不是真的。这是因为

Assert

在 two 条件上引发异常：其中一个是运行时条件，即第一个参数，第二个条件是编译时条件，也就是说，它取决于编译器选项。一些构建配置使用标志强制编译器使用断言（最常见的是，此类配置被命名为

DEBUG

），而其他配置则完全忽略断言，然后与断言相关的代码不会进入编译后的代码。

对于实际应用来说，这个机制是最重要的。这样，您只能在开发期间使用断言，并且它们非常有用。然而，对于生产版本，断言机制已从代码中完全删除。在完全开发、经过良好调试和测试的代码中，您不需要浪费任何 CPU 时间来对断言所使用的条件进行冗余检查。它使得断言机制对于开发非常有用。

那么，您是否也应该根据运行时条件抛出异常？在某些情况下，您可以，但不是很多情况，与可以广泛使用的断言相反，这取决于开发风格。

对于显式抛出的异常，您需要了解无论构建配置和任何设置如何，它们都会被抛出，因此您需要小心并三思而后行。在很多情况下，这不是一个好的做法。