请问一个微妙的有关问题
请教一个微妙的问题
我在这里简化了问题的描述，如下：
写了一个类，包含了2个函数：
SetRect(rect)
{
if(rect is invalid)
return ERR_CODE;
m_rect = rect;
}
UseRect()
{
//use m_rect......;
}
用户必须要先调用SetRect, 再调用UseRect. 如果客户传递了错误的rect给SetRect,返回ERR_CODE， 如果此时再调用UseRect,那么程序会崩溃。
现在的问题是：假如客户调用了SetRect的时候，传递了错误的rect,但是用户没有检查返回的错误码就去调用UseRect, 这样的话，程序就会崩溃。
那么，我是否应该在类中维护一个错误码，然后在UseRect()中也检查？（现实的情况是：在UseRect前有一系列步骤要走，每个情况下用户都可能忽略错误码而继续往下走） 还是应该把责任归咎于用户？
------解决方案--------------------
你可以自己检测合法性，并抛出异常交由用户处理
------解决方案--------------------
如果每次都要调用set在调用use，
你做成一个函数，先完成set，在use，这样就不会没set就use了
------解决方案--------------------
你在set时检查是否非法，为什么在use时不检查？每次都检查是基本原则，你不能不加检查的就使用一些可能导致崩溃的东西
------解决方案--------------------
如果我没有理解错的话，你的SetRect函数与operator=很类似。都是关于设置类状态的。只有正确地设置了类状态，类的其它成员函数才能够正确地运行。但是用返回值传递错误代码的办法是C-style。在设计和使用类的时候应当尽量少用。
解决办法有两种。第一种类似于fstream的做法：
1、在类中增加一个标志位，表示对象的状态。true表示对象被正确创建，false表示对象未被创建。
2、在每一个成员函数调用的过程中检测状态标志。
第二种方法显得比较面向对象一点：
1、用构造函数和拷贝赋值符来代替SetRect。其中如果出错，则抛出异常。
2、在使用类对象的地方处理该异常。
------解决方案--------------------
不太好的办法：
弄个默认值，如果客户没有按照你的套路出牌，就用默认的，在set里检测严格就好了，如果用户设置的不对，就用默认的。也可以在构造函数中加上set的内容，这样，他只要用你的类，就要set了。可以设置为必须显式构造。
一般的办法：
在Use里面加上严格的判断，如果没有正确的set，返回，什么都不干。
比较好的办法；
在Use里面加上严格的判断，如果没有正确的set，就直接异常（使用ASSERT也行的），MFC中常见的，显时的告诉客户哪里有问题。在没有办法把错误提前到编译时之前，我比较赞同这种方法。因为作为基础的东西，都用自己使用的规则，不可能那么智能的，客户程序怎么调用，怎么有的。这样的话不如不分什么是基础，什么是客户。所以最好原则就是在最早的时间让客户发现自己的错误。我觉得这个办法可以让写客户程序的工作者在运行发现这个问题，是个好办法
最好办法：
设计出来在编译时就能发现问题的类来。这样的方法我也不会，而且也不是万能的，
还有就是没有use,只有Set，活着只有Use没有Set，前者在Set之后直接自动的使用。后者是在Use里添加输入参数，直接使用该参数的东西。但是有可能你需要Set后不立即作Use的事情，这种方法就不适合了
------解决方案--------------------
保证状态正确是用户的责任,但是检测并汇报当前状态是类的责任.
因此,当出现问题时,UseRect必须告知用户,用throw exception的方式是最好的.
而类自身的崩溃是不可取的;相反,如果用户对异常置之不理,导致程序退出,就是用户的问题了.
此外,为了提醒用户SetRect失败的情形,最好在SetRect中也以throw exception代替return error code.
我在这里简化了问题的描述，如下：
写了一个类，包含了2个函数：
SetRect(rect)
{
if(rect is invalid)
return ERR_CODE;
m_rect = rect;
}
UseRect()
{
//use m_rect......;
}
用户必须要先调用SetRect, 再调用UseRect. 如果客户传递了错误的rect给SetRect,返回ERR_CODE， 如果此时再调用UseRect,那么程序会崩溃。
现在的问题是：假如客户调用了SetRect的时候，传递了错误的rect,但是用户没有检查返回的错误码就去调用UseRect, 这样的话，程序就会崩溃。
那么，我是否应该在类中维护一个错误码，然后在UseRect()中也检查？（现实的情况是：在UseRect前有一系列步骤要走，每个情况下用户都可能忽略错误码而继续往下走） 还是应该把责任归咎于用户？
------解决方案--------------------
你可以自己检测合法性，并抛出异常交由用户处理
------解决方案--------------------
如果每次都要调用set在调用use，
你做成一个函数，先完成set，在use，这样就不会没set就use了
------解决方案--------------------
你在set时检查是否非法，为什么在use时不检查？每次都检查是基本原则，你不能不加检查的就使用一些可能导致崩溃的东西
------解决方案--------------------
如果我没有理解错的话，你的SetRect函数与operator=很类似。都是关于设置类状态的。只有正确地设置了类状态，类的其它成员函数才能够正确地运行。但是用返回值传递错误代码的办法是C-style。在设计和使用类的时候应当尽量少用。
解决办法有两种。第一种类似于fstream的做法：
1、在类中增加一个标志位，表示对象的状态。true表示对象被正确创建，false表示对象未被创建。
2、在每一个成员函数调用的过程中检测状态标志。
第二种方法显得比较面向对象一点：
1、用构造函数和拷贝赋值符来代替SetRect。其中如果出错，则抛出异常。
2、在使用类对象的地方处理该异常。
------解决方案--------------------
不太好的办法：
弄个默认值，如果客户没有按照你的套路出牌，就用默认的，在set里检测严格就好了，如果用户设置的不对，就用默认的。也可以在构造函数中加上set的内容，这样，他只要用你的类，就要set了。可以设置为必须显式构造。
一般的办法：
在Use里面加上严格的判断，如果没有正确的set，返回，什么都不干。
比较好的办法；
在Use里面加上严格的判断，如果没有正确的set，就直接异常（使用ASSERT也行的），MFC中常见的，显时的告诉客户哪里有问题。在没有办法把错误提前到编译时之前，我比较赞同这种方法。因为作为基础的东西，都用自己使用的规则，不可能那么智能的，客户程序怎么调用，怎么有的。这样的话不如不分什么是基础，什么是客户。所以最好原则就是在最早的时间让客户发现自己的错误。我觉得这个办法可以让写客户程序的工作者在运行发现这个问题，是个好办法
最好办法：
设计出来在编译时就能发现问题的类来。这样的方法我也不会，而且也不是万能的，
还有就是没有use,只有Set，活着只有Use没有Set，前者在Set之后直接自动的使用。后者是在Use里添加输入参数，直接使用该参数的东西。但是有可能你需要Set后不立即作Use的事情，这种方法就不适合了
------解决方案--------------------
保证状态正确是用户的责任,但是检测并汇报当前状态是类的责任.
因此,当出现问题时,UseRect必须告知用户,用throw exception的方式是最好的.
而类自身的崩溃是不可取的;相反,如果用户对异常置之不理,导致程序退出,就是用户的问题了.
此外,为了提醒用户SetRect失败的情形,最好在SetRect中也以throw exception代替return error code.