How should I handle invalid values passed to a setter method?

If I have a simple class such as...

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; }
};

...and the person using it calls the mutator setWidth() with an invalid argument, say -1.0, what is the correct way to handle this? When I say correct, should I for example, change the return type from void to bool or possibly an int and return a value to indicate whether or not the operation occurred successfully, or am I to allow the value to be set since theoretically it will not break anything, but any values returned as a result, say from getArea() will be garbage and the user will have to debug what he/she did wrong?

Sorry if this is a silly question, but two text books later, and I'm still 开发者_开发问答not quite sure about how classes I write should be implemented for others to use.

You have a couple choices. In the real world, it will depend on who is using your class (other internal code or public API) as well as conventions agreed upon by your company.

You can:

Throw Exception

Pros:

1. Simple to implement
2. Keeps error handling code clean
3. Allows passing of error messages and other variables
4. Standard for most exceptional situations
5. Harder to ignore than a boolean return
6. Can be thrown from constructor

Cons:

1. Can be overused in areas where normal conditional statements should be used (this situation doesn't count)
2. You are introducing more "invisible" breaking points into an application. Many times users of a class don't know what exactly is going to be thrown because it either isn't documented or he/she didn't read the documentation.

Assert

Pros:

1. Rule of thumb: if you are going to crash, crash early
2. Good for situations where you as the developer call the code and have control over the input
3. Strong debugger support (typically)

Cons:

1. Gets excluded from non-debug builds so not good for times when user can still input bad data

Boolean Returns

Pros:

1. Quick/Easy to implement
2. Smaller footprint than exception handling (although this is negligible these days)

Cons:

1. Can't pass back any extra information to the caller (why did it break?)
2. Breaks down when you are trying to be consistent through your entire project and a simple boolean won't cut it
3. Easier to ignore compared to exceptions

Evaluate Data Type

Don't be afraid to go back and check if the data type of your property makes sense for what you are doing. In this case, it does. However, I can think of times where developers have used standard integers when they really wanted unsigned integers or strings when they really needed a single character.

You should throw an exception:

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

Depends on the usage of the class.

If you want a user friendly message to be passed on to caller, you can put an if condition and throw an exception (e.g. std::invalid_argument) with a good description. Update the documentation and signature appropriately of course.

If you expect this should never happen in real life, but can happen in, say testing phase of the development, then I recommend using assert. As in production/release build the asserts are "removed" from code by compiler. So while testing (debug build, e.g. -DNDEBUG and/or -g option for gcc) if someone makes a mistake, you'll see a clear assertion failure, but in real/production environment no error would be reported and the extra condition won't harm the performance.

Usually when compiler is invoked with -DNDEBUG option, it's

Some references for assert and throw syntax.

Either return false; or throw something like invalid_value.

How an error should be handled is completely requirement/project dependent. If your project require to continue with wrong user input (which could be very dangerous in real life software) that's what you need to do. Similarly, if the project needs protection against wrong user input, that must be addressed.

When you design a class to be used by other user, you must make sure it can't be used any wrong way. You must fool proof your code. If any bug emerges from the software where your class will be used, you should write the class in such a way so that the bug doesn't come out from your code.