如果建议断言后的条件

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);
    }

    // ...
}

条件是我可以控制的（即它不依赖于用户交互或其他东西）并且它确定了我的代码的正确性，因此异常就出来了。

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

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

违反条件的行为不是非常致命的。如果没有父节点，除了没有空检查的方法调用失败之外，什么都不会发生（在发布版本中）。

但更重要的是，它表明Model类的客户端正在做一些不合逻辑的事情。我想指出一个事实（至少在调试期间）我的客户端代码中有一些我显然没有想过的东西，因为如果我有，那么条件就不会发生。

Answer 1

当某些真正错误的条件成立时，会使用断言。错误是异常是不够的。它通常用于检测代码中的逻辑错误。

是否在您的具体示例中使用它取决于。您是否100％确定ParentModel应该是非null，并且如果它为null，则表示发生了一些真正意外和错误的事情，您必须停止该程序？如果是，那么你可以使用Debug.Assert。否则，执行null检查，如果为null，则通过其他方式处理它，而不是终止程序。

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

了解更多here和here。