Question

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.

Answer 1

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.