我正在与一位同事讨论从构造函数抛出异常的问题，我想我需要一些反馈。
从设计的角度来看，从构造函数抛出异常是否正确?
假设我在一个类中包装了一个POSIX互斥锁，它看起来像这样:
class Mutex {
public:
Mutex() {
if (pthread_mutex_init(&mutex_, 0) != 0) {
throw MutexInitException();
}
}
~Mutex() {
pthread_mutex_destroy(&mutex_);
}
void lock() {
if (pthread_mutex_lock(&mutex_) != 0) {
throw MutexLockException();
}
}
void unlock() {
if (pthread_mutex_unlock(&mutex_) != 0) {
throw MutexUnlockException();
}
}
private:
pthread_mutex_t mutex_;
};
我的问题是，这是标准的方法吗?因为如果pthread mutex_init调用失败，互斥锁对象将不可用，因此抛出异常将确保不会创建互斥锁。
我是否应该为Mutex类创建一个成员函数init，并调用pthread mutex_init，其中将返回基于pthread mutex_init的返回的bool值?这样我就不必为如此低级的对象使用异常了。
如果您的项目通常依赖异常来区分坏数据和好数据，那么从构造函数抛出异常比不抛出更好。如果没有抛出异常，则对象将初始化为僵尸状态。这样的对象需要公开一个标志，说明该对象是否正确。就像这样:
class Scaler
{
public:
Scaler(double factor)
{
if (factor == 0)
{
_state = 0;
}
else
{
_state = 1;
_factor = factor;
}
}
double ScaleMe(double value)
{
if (!_state)
throw "Invalid object state.";
return value / _factor;
}
int IsValid()
{
return _status;
}
private:
double _factor;
int _state;
}
这种方法的问题在于调用方。类的每个用户在实际使用对象之前都必须执行一个if。这是对bug的呼吁——没有什么比在继续之前忘记测试一个条件更简单的了。
如果从构造函数抛出异常，构造对象的实体应该立即处理问题。下游的对象消费者可以自由地假设对象是100%可操作的，因为他们获得了对象。
这个讨论可以在很多方面继续下去。
例如，将异常用作验证是一种糟糕的实践。一种方法是将Try模式与工厂类结合使用。如果你已经在使用工厂，那么写两个方法:
class ScalerFactory
{
public:
Scaler CreateScaler(double factor) { ... }
int TryCreateScaler(double factor, Scaler **scaler) { ... };
}
使用此解决方案，您可以就地获得状态标志，作为工厂方法的返回值，而无需使用坏数据进入构造函数。
第二件事是如果你用自动化测试覆盖代码。在这种情况下，使用不抛出异常的object的每段代码都必须包含一个额外的测试——当IsValid()方法返回false时，它是否正确工作。这很好地解释了在僵尸状态下初始化对象是一个坏主意。
