异常处理 - 这是一种好的做法吗?

bar*_*zek 4 .net c# exception-handling exception

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

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;
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

用户将使用SetRange()方法设置值.但他有一些约束,比如Min必须大于Max,并且它们都不应该大于100或小于0.

我应该在这个地方使用这些例外吗?或者有更好的方法来处理错误的用户输入?我希望我的问题不是一般性的.

Dav*_*vid 9

这是一种合适的做法,是的.

虽然我想消费代码会期待一种ArgumentException而不是这种异常类型,但这可能是一个相对较小的一点.

当输入无效,并且对象无法以其他方式有意义地继续时,则抛出异常是适当且预期的响应.由消耗代码来正确使用对象,处理错误,向用户报告等等.

替代方案是这个对象"试图弄清楚要做什么",这通常会导致一些非常糟糕的编码实践.例如...

  • 假设您想要返回错误消息而不是抛出异常.如果使用代码不检查该错误消息怎么办?该对象将处于未知和无效状态,可能会悄悄地引入错误.如果消费代码没有检查异常,那么程序将明显地显然失败并且需要进行适当的纠正.清除和明显的失败是很多比微妙和被忽视的人更容易支持.
  • 假设您想要"向用户显示消息".这需要将此对象紧密耦合到表示层,这会破坏面向对象的原则并使代码非常严格且难以维护.

这个对象做了一件事,只做了一件事.如果以不能做那件事的方式调用它,则异常是预期的和适当的失败条件.