Reputation: 75
Suppose we have an implementation of the abstract factory which is invoked as follows:
std::string ObjectName = "An Object Name";
std::string Args = "Argument passed directly to constructor by the factory";
std::unique_ptr<MyBaseClass> MyPtr(ObjectFactory::Instance().Construct(ObjectName,Args));
The factory uses a std::map
to turn "An Object Name"
into a constructor, which itself takes a std::string
as an argument. The idea is that the user knows more about the constructed objects than I do, so I should get out of the way and let the user pass any information they want to the constructor.
This works fine when Args
is in exactly the form expected but I don't know the most idiomatic way of handling duff inputs. What should happen if a user supplies an invalid argument string?
I can think of the following:
bool Validate(std::string x)
method, which checks whether x
is a valid argument stringbool
member variable which, if true, means "this object is not in a sane state"Upvotes: 2
Views: 173
Reputation: 315
What ever you do, do not throw an exception from a constructor (as per Item #10 in More effective C++), as the destructor will not be called. It leads to newbie memory leaks and forces users to worry about exception handling.
I would just assert and return a Null Object, with dummy factory method implementations, or return nullptr.
Upvotes: -3
Reputation: 67584
Throw an exception. You're constructing an object (albeit in a different way than just new
), failure is an exception that needs to be handled if it can happen.
"Solution 2" has nothing to do with handling this issue, it's more of a how to determine bad input. For such it can be an acceptable solution, but again it has nothing to do with the question at hand.
Solution 3 leaves the object in an indeterminate state in case of failure, which is unacceptable.
Solution 4 is another way to do it, and the only way if you don't have exception support in your language, but we do. Exceptions in this case are strictly better in my opinion because failing to construct an object is an action so destructive it should require alternative code or the program to die.
Upvotes: 6
Reputation: 2369
The first solution is the standard solution for constructor failure. Solution #2 and #4 are pretty error prone (user might forget to check) Solution #3 doesn't solve the problem
If you're making a library or just writing code that might be re-used in a "no exceptions allowed" environment, you could consider returning std::unique_ptr{nullptr}. Even if it is also error prone, that's the other standard way of handling construction failure.
Upvotes: 2