How to handle incorrect values in a constructor?

Question

Please note that this is asking a question about constructors, not about classes which handle time.

Suppose I have a class like this:

class Time
{
protected:
    unsigned int m_hour;
    unsigned int m_minute;
    unsigned int m_second;
public:
    Time(unsigned int hour, unsigned int minute, unsigned int second);
};

While I would want a to be constructed successfully, I would want the constructor of b to fail.

Time a = Time(12,34,56);
Time b = Time(12,34,65); // second is larger than 60

However, this is not possible, because constructors do not return any values and will always succeed.

How would the constructor tell the program that it is not happy? I have thought of a few methods:

1. have the constructor throw an exception, and have handlers in the calling function to handle it.
2. have a flag in the class and set it to true only if the values are acceptable by the constructor, and have the program check the flag immediately after construction.
3. have a separate (probably static) function to call to check the input parameters immediately before calling the constructor.
4. redesign the class so that it can be constructed from any input parameters.

Which of these methods is most common in industry? Or is there anything I may have missed?

Answer 1

Typically you'd have a private/protected constructor and a public static factory method to create the Time object. It is not a good idea to throw an exception from a constructor because it wreaks havoc on inheritance. This way your factory method can throw an exception if needed.

Answer 2

First one is the best, exceptions are the best way to inform the class users about the errors.

it is not recommended another way because if the constructor returns without erros, it means you have constructed an object correctly and you can use it anywhere

Answer 3

I don't think you have much choice.

If you got invalid input you can't do much than signal to the caller than it is invalid. You can then use exception or error code.

Error code in a constructor would need to be passed as a reference parameter and as such would look very akward.

You could try to find how you could validate the inputs at the source. Why are you getting invalid input exactly? How can the input be invalid, etc.

An example for your date class would be to force the user (user of your program) to enter a valid date only (by forcing him to enter it in a calendar type GUI, for example).

You could also try to create a method in your class to handle input validation.

With that, the user (programmer this time) can either call it before construction and be sure that the call will not fail or fall back on exception if the user did not validate it.

If performance is important and you do not want to call the validate function twice (user call it, then in the constructor), I think you could use the named constructor idiom to have a CheckedConstructor and an UncheckedConstructor.

This is beginning to be architectural overdoing though, I think.

In the end, it would depend on the class and use case.

Answer 4

"Exception thrown from a C'tor" is not a four-letter word. If an object can not be created correctly, the C'tor should fail, because you'd rather fail in construction than having an invalid object.

Answer 5

Just to elaborate a bit on the answers given by onebyone and Timbo. When people discuss the use of exceptions, usually someone eventually says: "Exceptions should be used in exceptional situations."

As you can tell from the most of the answers here, if a constructor fails then the correct response is to throw an exception. However, in your case, it is not necessarily that you cannot create the object, it's more that you don't want to create it.

Where the values are being read from an external source (eg. a file or a stream) there is a good chance that invalid values will be received and in that case, then it's not really an exceptional situation.

Personally, I would lean towards validating the arguments before constructing the time object (something like Timbo's answer) and I would then have an assertion in the constructor to verify that they arguments are valid.

In the case that your constructor needs a resource (eg. allocates memory) then that, IMHO, would be closer to an exceptional situation and so you would then throw an exception.