This is broken. Theres no common-good in allowing invalid objects to be created. Constraints and validation are important in all parts of a system, and ctors is just one of the units that also need to perform checks to ensure this is true.
If you really wanted to go down the author's route, then you'd at least make the constructor private, and have a static method that returns a valid constructed object or an error, so you never have e.g. an "unconnected" database connection:
But I wouldn't even bother with this - it's exceptions with extra steps. I seem to remember that Stroustrop said in the Design and Evolution of C++ that the main reason for adding exceptions in the first place was to allow a failure result from a constructor.
> The C++ container classes assume noexcept constructors for this reason, because creating a list of size 20 calls your constructor 20 times, and the cleanup gets so much messier.
No, STL containers such as std::vector definitely do not assume (nor require) non-throwing constructors. They just do the right thing. Yes, cleanup is messier than it would otherwise be.
STL containers do require that your destructors not throw (but do not require that they be noexcept).
Constructors are dedicated language-sanctioned functions that transform (data inputs X) into (type/object Y).
The given X should be subjected to the requirements necessary to create a valid Y. If the requirements fail, you have two main choices: Create an invalid Y, or reject X & return an error in however you want it to be returned.
The former leaks said rejections throughout the rest of the type's/object's code, & makes more work for me to parse through where & how the problem occurs.
The latter option creates a cleaner system altogether, due to rejecting sections of invalid states. Not all will be rejected, but the fact that some do get rejected already makes its workload comparatively lighter than the former.
Trying to keep an open mind here–if your constructor arguments are plain wrong then who should be throwing the error then? The Factory? The Builder? And what if they don't exist in the first place?
> Because the semantics of a constructor is to bring an object into a valid state and you don’t expect it to perform any functionality.
No, I expect it to perform the functionality of bringing the object into a valid state - whatever functionality that takes. And if it can't, then throwing is the next option, because it's preferable to having an object in an invalid state.
At one point they needed a custom build of AIX because its executable size limit of 1GB wasn't enough for the big. This was about 20 years ago, I suppose that seems quaint now.
this is not helpful, please explain why you think this
If we interpret "constructor" more generically as setup, one of my preferred languages, Go, does not have constructors, but we do have similar setup functions, which typically return errors, and we handle them as soon as possible without breaking out from the designed control flow.
yes, I use init sparingly and generally panic, for low level program startup, versus the NewFoo functions, which are for dynamic objects the way constructors are used, I use NewFoo -> (Foo, error) for internal runtime, client, and configuration handling as well
I think elsewhere in this thread the point has already been made so I thought to spare the Ink. A constructor is essentially a function that returns a value. There's little reason to think that constructors are more than that. A few examples: in JS, a constructor is a method called `constructor()`. It's a bit special in that it's the method that is privileged to be the one called when the class name is preceded by the keyword `new`, but that's almost about it. It can be replaced or supported by one or more factory functions, and this is what happened with NodeJS's `Buffer` class and generals JS's `Array` class. In Ruby, the constructor is just a method called `new()`, and I guess it's not special beyond there being a convention to construct new instances with a method called `.new()`. Like any function, a constructor has an input and an output value. For example, in `new Point 3, 4` the input is the pair of numbers `( 3, 4 )` (here written spread out, but it doesn't matter), and its output is an instance of class `Point`. Say you have a class List that accepts as only parameter the length (number of elements) of the `List`. When I call a function `build_list length: -4` I expect the `length` argument to be suitably interpreted, or an error to be thrown. Most of the time a list with a negative number of elements does not make a lot of sense, so the natural thing is to indicate an error, which in many current languages is done by throwing an exception so as to prevent silent failures. When I call a constructor as `new List length: -4` I naturally expect the exact same considerations to apply.
This is broken. Theres no common-good in allowing invalid objects to be created. Constraints and validation are important in all parts of a system, and ctors is just one of the units that also need to perform checks to ensure this is true.
Absolutely agreed.
If you really wanted to go down the author's route, then you'd at least make the constructor private, and have a static method that returns a valid constructed object or an error, so you never have e.g. an "unconnected" database connection:
But I wouldn't even bother with this - it's exceptions with extra steps. I seem to remember that Stroustrop said in the Design and Evolution of C++ that the main reason for adding exceptions in the first place was to allow a failure result from a constructor.> The C++ container classes assume noexcept constructors for this reason, because creating a list of size 20 calls your constructor 20 times, and the cleanup gets so much messier.
No, STL containers such as std::vector definitely do not assume (nor require) non-throwing constructors. They just do the right thing. Yes, cleanup is messier than it would otherwise be.
STL containers do require that your destructors not throw (but do not require that they be noexcept).
Containers also give more efficient and simpler semantics if move constructors are noexcept, which they generally should be.
Constructors are dedicated language-sanctioned functions that transform (data inputs X) into (type/object Y).
The given X should be subjected to the requirements necessary to create a valid Y. If the requirements fail, you have two main choices: Create an invalid Y, or reject X & return an error in however you want it to be returned.
The former leaks said rejections throughout the rest of the type's/object's code, & makes more work for me to parse through where & how the problem occurs.
The latter option creates a cleaner system altogether, due to rejecting sections of invalid states. Not all will be rejected, but the fact that some do get rejected already makes its workload comparatively lighter than the former.
I know which my lazy bum would pick.
Trying to keep an open mind here–if your constructor arguments are plain wrong then who should be throwing the error then? The Factory? The Builder? And what if they don't exist in the first place?
> Turn your Database class into a state machine with an uninitialized and a connected state. Then have a Database.connect()
It's a bad advice. It's preferred instead to have a connect function returning a database instance in a successful case or an error otherwise.
> Because the semantics of a constructor is to bring an object into a valid state and you don’t expect it to perform any functionality.
No, I expect it to perform the functionality of bringing the object into a valid state - whatever functionality that takes. And if it can't, then throwing is the next option, because it's preferable to having an object in an invalid state.
neither should destructors, my first internship was at Bloomberg and I put a BIG into a crash loop with this
Ah, the "big". That's some fun insider knowledge!
At one point they needed a custom build of AIX because its executable size limit of 1GB wasn't enough for the big. This was about 20 years ago, I suppose that seems quaint now.
when I was there, the bigs were 4 gig, ~2009±1
for others context, bigs were the compiled binary deployed to a server, a composition of BB terminal functions, bin packing style
> Constructors Shouldn't Throw
wrong
this is not helpful, please explain why you think this
If we interpret "constructor" more generically as setup, one of my preferred languages, Go, does not have constructors, but we do have similar setup functions, which typically return errors, and we handle them as soon as possible without breaking out from the designed control flow.
In go there are the "init" functions, but those do not return a possible error result.
I guess you're thinking more of package constructor methods, such as NewFoo, which tend to return the new object and an error value.
yes, I use init sparingly and generally panic, for low level program startup, versus the NewFoo functions, which are for dynamic objects the way constructors are used, I use NewFoo -> (Foo, error) for internal runtime, client, and configuration handling as well
I think elsewhere in this thread the point has already been made so I thought to spare the Ink. A constructor is essentially a function that returns a value. There's little reason to think that constructors are more than that. A few examples: in JS, a constructor is a method called `constructor()`. It's a bit special in that it's the method that is privileged to be the one called when the class name is preceded by the keyword `new`, but that's almost about it. It can be replaced or supported by one or more factory functions, and this is what happened with NodeJS's `Buffer` class and generals JS's `Array` class. In Ruby, the constructor is just a method called `new()`, and I guess it's not special beyond there being a convention to construct new instances with a method called `.new()`. Like any function, a constructor has an input and an output value. For example, in `new Point 3, 4` the input is the pair of numbers `( 3, 4 )` (here written spread out, but it doesn't matter), and its output is an instance of class `Point`. Say you have a class List that accepts as only parameter the length (number of elements) of the `List`. When I call a function `build_list length: -4` I expect the `length` argument to be suitably interpreted, or an error to be thrown. Most of the time a list with a negative number of elements does not make a lot of sense, so the natural thing is to indicate an error, which in many current languages is done by throwing an exception so as to prevent silent failures. When I call a constructor as `new List length: -4` I naturally expect the exact same considerations to apply.