c# - 异常处理——这是好的做法吗？

Question

我想知道我要做的是好事还是坏事。我有那个课:

public class Element : IElement
{
    public float? Max { get; private set; }

    public float? Min { get; private set; }

    public float? Average { get; private set; }

    public bool HasValue { get; private set; }


    public void SetRange(float? min, float? max)
    {
        if (min >= max)
        {
           throw new WrongElementValueException("Min must be greater than max!");
        }
        else if (min < 0f || max < 0f)
        {
           throw new WrongElementValueException("Min/max must be greater than 0!");
        }
        else if (min > 100f || max > 100f)
        {
           throw new WrongElementValueException("Min/max must be lesser than 0!");
        }
        else
        {
            Min = min;
            Max = max;
            Average = (min + max)/2f;
            HasValue = true;
        }
    }
}

用户将使用 SetRange() 方法设置值。但是他有一些限制，比如 Min 必须大于 Max，并且两者都不能大于 100 或小于 0。

我应该在这个地方使用那些异常(exception)吗？还是有更好的方法来处理错误的用户输入？ 我希望我的问题不是笼统的。

Answer 1

这是一种适当的做法，是的。

虽然我想消费代码会期待 ArgumentException 而不是这种异常类型，但这可能是一个相对次要的问题。

当输入无效，并且对象无法以其他方式有意义地继续时，抛出异常是一种适当且预期的响应。正确使用对象、处理错误、向用户报告等都取决于消费代码。

另一种方法是让这个对象“试着找出要做什么”，这通常会导致一些非常糟糕的编码实践。例如……

• 假设您想要返回一条错误消息而不是抛出异常。如果使用代码不检查该错误消息怎么办？该对象将处于未知和无效状态，并可能悄悄地引入错误。而如果使用代码不检查异常，那么程序显然会失败，需要进行适当的更正。与微妙和未被注意的失败相比，明显和明显的失败很多更容易支持。
• 假设您想要“向用户显示一条消息”。这将需要将该对象与表示层紧密耦合，这违背了面向对象的原则，并使代码非常僵硬且难以维护。

这个对象做一件事，而且只做那一件事。如果它的调用方式使其不能做那件事，则异常是一种预期且适当的失败条件。