初始化不正确值错误样式后是否抛出异常？

Question

以下定义是坏风格还是纯错误？也就是说，在初始化一个被认为不正确的值之后抛出是错误的吗？

myClass::myClass(int arg) : value(arg) 
    { 
    if (value < 0) 
     throw (myException("Negative value not allowed!")); 
    } 

看来最好使用初始化器列表上分配在体内的价值，从我的理解，如果我前扔后的值已分配或不要紧。

Answer 1

如果value> = 0是一个类不变量，那么你真的只有一些可能性。一种方法是编写ctor以接受unsigned参数，因此仅仅是不可能的。另一个是抛出异常。

但是，如果用户传递的值不能创建有效的对象，那么抛出异常是完全可以接受的（并且通常是正确的）。构造函数的责任是创建一个有效的对象。如果它传递了一个无法创建有效对象的值，那么异常通常是正确的响应。

至于当抛出异常：至少在这种情况下，它并不重要。异常将回滚当前对象的创建，因此它永远不会存在。如果首先测试该值的速度要快得多，而不是复制该值，然后在该值无效时将其摧毁，那么可能会有所不同。像int这几乎毫不相关。如果你拥有某种大树，并且只通过查看树的根节点来判断它是否有效，那么首先检查该节点可能会更好，并且只复制三个树如果它是有效的。

后者显然是一种优化，但可以是足够大和足够简单的一种，即使没有分析也可能是值得的（可以说，它只是避免了悲观化的优化）。

Answer 2

您正在使用构建器类型的初始化器列表，您没有获得任何性能优势，因此为什么不在构造器体内检查后对成员变量进行赋值。在你的情况下，你有一半创建非法对象，而不是一半创建的法律对象。那么为什么要给对象任何无效的状态，以便稍后被破坏。

从构造函数中抛出异常是可以的（在大多数情况下不是析构函数）。 如果你不能对他们传递的值做任何有意义的事情，即将任何负值颠倒为0，那么抛出异常似乎是要做的事情，毕竟你不能创建合法对象。

你可以使用一个unsigned int？ 0至4,294,967,295。使得对调用者更加明确，值必须大于0.

Answer 3

除非该类在紧密循环中被多次初始化，否则额外函数的性能损失可以忽略不计。这与初始化班不适当的损失相比，这是一个非常小的代价！特别是考虑到“坏值”可能是用户输入的结果，所以产生的问题可能难以报告/排除故障

Answer 4

一种替代方案，允许使用初始化程序列表并在初始化值之前抛出，如果参数不在有效范围内：

inline int RequirePositive(int value) 
{  
    if (value < 0) throw (myException("Negative value not allowed!")); 
    return value; 
} 

class myClass { 
    myClass(int arg) : value(RequirePositive(arg)) {} 
}; 

Answer 5

我不会这样做。简单地使用使用你的班级的人会明白这是使用它的明智原因的方法。