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，它意味着发生了一些真正意外和错误的事情，你必须停止程序吗？如果是，那么您可以使用Debug.Assert。否则，执行空检查，如果为null，则通过其他方式处理它，而不是终止程序。

另请注意，断言在发布模式下无法正常工作。要在发布模式下断言，请使用Trace.Assert。

了解详情here和here。

如果建议断言后的条件

1 个答案: