Unless they are told to do so, future programmers will not be inclined to surround these constructor calls with defensive code. Exceptions and errors inside of a constructor are very unexpected.To that, I would reply, "Well that may be true, until it isn't."
#Parameterized constructor code
One could reasonably question these guidelines and say, "But I don't follow these rules, and my code works fine!" A constructor should not throw exceptions or log errors. For instance, I always shudder when I see a try-catch block inside a constructor.A constructor should be light and should never fail.A constructor with side-effects breaks the Single-Responsibilty-Principle (SRP) and runs contrary to the spirit of object-oriented-programming (OOP).Anything more than private field initialization should be viewed as a side-effect.
A constructor shouldn't have any side-effects.That's a lot of extra work though for questionable gain (maybe even loss). Since the only way to create a funky_object is by calling build_funky the principle of never allowing an invalid object to exist remains intact even though the actual "Constructor" doesn't finish the job. For example, something like this in C++ wouldn't violate the principle IMNSHO: struct funky_objectįriend boost::optional build_funky(std::string) īoost::optional build_funky(std::string str) That could just as easily be something other than an actual construct that goes by the name "Constructor". I should note that by "constructor" I mean the thing the client calls to build the object. Some day down the road, I or someone else will probably pay the price for that slip in practice. I did it the other day for a very narrowly used object within a tight scope. This includes not providing complete constructors (like having an empty constructor + initialize() before your object is actually completely built).JUST SAY NO! NEVER allow an object to exist in an inconsistent state.
Throw an exception IFF the class cannot be put into a consistent state with regard to its semantic use.
0 kommentar(er)
