Question

如果我有一个简单的课程，比如......

class Rectangle
{
  private:
    double length;
    double width;
  public:
    void setLength(double l) { length = l; }
    void setWidth(double w) { width = l; }
    void getLength() { return length; }
    void getWidth() { return width; }
    void getArea() { return length * width; }
};

...并且使用它的人使用无效参数调用mutator setWidth（），比如说-1.0，处理这个问题的正确方法是什么？当我说正确的时候，我应该例如将返回类型从void更改为bool或者可能是int并返回一个值来指示操作是否成功发生，或者我是否允许设置该值，因为理论上它将会没有破坏任何东西，但是从getArea（）返回的任何值都是垃圾，用户必须调试他/她做错了什么？

很抱歉，如果这是一个愚蠢的问题，但后来有两本教科书，我仍然不太确定我应该如何实施我写的课程以供其他人使用。

Answer 1

你有几个选择。在现实世界中，它将取决于谁使用您的类（其他内部代码或公共API）以及贵公司商定的约定。

你可以：

抛出异常

优点：

易于实施
保持错误处理代码清洁
允许传递错误消息和其他变量
大多数特殊情况的标准
比布尔返回更难忽略
可以从构造函数

缺点：

可以在应该使用正常条件语句的区域中过度使用（这种情况不计算在内）
您正在向应用程序中引入更多“不可见”的断点。很多时候，类的用户不知道究竟会抛出什么，因为它没有记录，或者他/她没有阅读文档。

断言

优点：

经验法则：如果你要崩溃，早点崩溃
适用于开发人员调用代码并控制输入的情况
强大的调试器支持（通常）

缺点：

从非调试版本中排除，因此用户仍然可以输入错误数据的时间不佳

布尔返回

优点：

快速/易于实施
比异常处理更小的占地面积（尽管现在可以忽略不计）

缺点：

无法将任何额外信息传回给来电者（为什么会中断？）
当你试图在整个项目中保持一致并且简单的布尔值不会削减它时会崩溃
与异常相比更容易被忽略

评估数据类型

不要害怕返回并检查您的财产的数据类型是否对您正在做的事情有意义。在这种情况下，确实如此。但是，我可以想到开发人员在真正需要单个字符时真正想要无符号整数或字符串时使用标准整数的时间。

Answer 2

你应该抛出异常：

#include <stdexcept> 
// ...
void setLength(double len)
{ 
    if (len < 0)
        throw new std::invalid_argument("len"); 
    length = len;
}

Answer 3

取决于课程的用法。

如果您希望将用户友好的消息传递给调用者，您可以将if条件和throw异常（例如std::invalid_argument）放在一个良好的描述中。当然，请适当更新文档和签名。

如果你认为这应该永远不会发生在现实生活中，但可能发生在开发的测试阶段，那么我建议使用assert。在生产/发布版本中，断言由编译器从代码中“移除”。因此，在测试（调试构建，例如gcc的-DNDEBUG和/或-g选项）时如果有人犯了错误，你会看到明确的断言失败，但在实际/生产环境中没有错误会是报告并且额外条件不会损害性能。

通常在使用-DNDEBUG选项调用编译器时，它是

assert和throw语法的一些参考。

Answer 4

return false;或throw类invalid_value。

Answer 5

如何处理错误完全取决于需求/项目。如果您的项目需要继续错误的用户输入（这在现实生活中可能非常危险），那就是您需要做的事情。同样，如果项目需要防止错误的用户输入，那么必须解决这个问题。

当您设计一个供其他用户使用的类时，您必须确保它不能以任何错误的方式使用。你必须愚弄你的代码。如果从使用您的类的软件中出现任何错误，您应该以这样的方式编写该类，以便不会从您的代码中产生错误。

我应该如何处理传递给setter方法的无效值？

5 个答案:

抛出异常

断言

布尔返回

评估数据类型