如果断言后的条件建议

Question

听起来很基本，但我没有找到现有的答案。抱歉，如果它是重复的。

我过去从未过多地使用断言，我可能还没有理解它们背后的精神。在方法 Remove() 中编写类似以下内容是推荐还是标准做法？

public class Model
{
public Model ParentModel {get; private set}
readonly List<Model> submodels = new List<Model>();
public Model AddSubmodel(Model m)
{
submodels.Add(m);
m.ParentModel = this;
}
public void RemoveSubmodel(Model m)
{
submodel.Remove(m);
m.ParentModel = null;
}
public void Remove()
{
Debug.Assert(ParentModel != null);
if (ParentModel != null) ParentModel.RemoveSubmodel(this);
}
// ...
}

条件是我可以控制的(即它不依赖于用户交互或其他东西)，它决定了我的代码的正确性，所以例外情况就出来了。

我这样做的理由是，我希望它在调试模式下失败，但我想在发布模式下尽可能多地修复它。

编辑：如评论中已经提到的，

条件违规本身并不是非常致命的。如果没有父级，除了方法调用在没有 null 检查的情况下失败之外，不会发生任何事情(在发布版本中)。

但更重要的是，它表明类模型的客户端正在做一些不合逻辑的事情。我想指出这样一个事实(至少在调试期间)，我的客户端代码中有一些我显然没有想到的东西，因为如果我有，这种情况就不会发生。

Answer 1

当某些真正错误的条件为真时，使用断言。这是错误的，一个例外是不够的。它通常用于检测代码中的逻辑错误。

是否在您的特定示例中使用它取决于。您是否 100% 确定ParentModel应该是非空的，如果它是空的，则意味着发生了真正意外和错误的事情，您必须停止程序？如果是，那么您可以使用Debug.Assert.否则，请执行 null 检查，如果为 null，则通过终止程序以外的其他方式处理它。

另请注意，断言在发布模式下不起作用。要在发布模式下断言，请使用Trace.Assert。

在此处和此处了解更多信息。