class design question

[lochnessmonster]

is it bad programming practice or perfectly normal to design a class, in which there is no public member function which can check the status of the objects state? for example what if i implemented it so the object was assumed successfull....until an exception is thrown? is this OK to do or no?

[StuXYZ]

Absolutely fine, (IMHO), obviously it depends on your needs, but what about classes that return some kind of evaluation, e.g. a class that calculates the global density from all the objects in a simulation. It knows the materials, object locations and orientations. It has only one public function that returns something and that is the calcDensity function.

[Fbody]

I would call it neither "bad practice" nor "perfectly normal". It really depends on your situation and whether or not it warrants it. I would call it "acceptable".

Ideally, your constructor would be written in such a way as to guarantee creation of a valid object. Additionally all of your other functions would be responsible for maintaining the validity of their specific part of the object. For example, if your object has a variable whose value must be between 1 and 10, the setVar() function/method responsible for that variable would have an internal check to make sure its new value stays within that range.

class Sample {
 private:
   int prvInt;          //an integer whose value must be between 1 and 10
 public:
   void setPrvInt(int newInt) {
     if (newInt < 1 || newInt > 10) //verify the value is valid
       //throw some sort of error
     else
       prvInt = newInt;             //if valid, perform the assignment
   }

   Sample():prvInt(0){} //default constructor
   Sample(int newInt) { //overloaded constructor
     setPrvInt(newInt); //set the value of prvInt
   }
};

[mike_2000_17]

Roughly speaking, you could say there are three types of classes. Those whose objects are:
1- Always in a valid state (and always constructed successfully)
2- Completely useless if not in a valid state
3- Could be in an invalid state and still be useful (or recoverable)

1- A trivial example of this is a simple POD class like a 3D vector class (holding coordinates x,y,z). Then, obviously, there is no need for a function to check the validity of the object's state because in itself any state is a valid state.

2- Not all, but many resource handling classes are of this type because the object is defined by the resource it holds. If it holds no resource (because it failed to acquire it), then it is meaningless. In this case, an existing object is a valid object, and thus, there is no need to have a function to check its status. Throwing an exception upon construction is a good way to abort any piece of code that uses the resource in case of a failure to acquire it.

3- To counter the above cases, there are many resource handling classes that can either allow a partially invalid state or lose its validity. A good example of both is the std::fstream from the standard C++ library. In this case, the class handles a resource (a file) and is generally constructed to open a file and closing it upon destruction (although the open() and close() functions are available too for convenience). So one might think that an fstream object is useless if it is not handling a file resource and you might be tempted to implement it as in case 2. However, a file can reach the end-of-file while reading it, which then becomes a partial invalid state because it cannot read any further, but it is still useful because you can seek another position in the file to re-read data. Also, you might want to try and open different files until you are successful (which would be awkward if you needed a try-catch clause for each try). A TCP socket is another example for which it seems useless if it is not connected but you might connect on construction but lose the connection later.

In conclusion, case 1 is trivial case where you don't need to check the state's validity. Case 3 is the most general case for many classes (resource handling or not) and does require at least an internal mechanism for dealing with an invalid state, and possibly an external mechanism too. But if you are sure that your class falls in case 2, then you don't need to check for validity (neither internally nor externally) which is obviously a benefit but this case is definitely more rare than the other two.