Constructors Shouldn't Throw(t3.at)

3 pointsby jcbhmr7 hours ago7 comments

MiroslavPokorny4 hours ago
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.
Panzerschrek44 minutes ago
> 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.
x-complexity3 hours ago
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.
quuxplusonean hour ago
> 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).
AnimalMuppet6 hours ago
> 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.
verdverm3 hours ago
neither should destructors, my first internship was at Bloomberg and I put a BIG into a crash loop with this
- quietbritishjim3 hours ago
  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.
  - verdverm3 hours ago
    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
DemocracyFTW24 hours ago
> Constructors Shouldn't Throw
wrong
- verdverm3 hours ago
  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.
  - stevekemp3 hours ago
    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.
    verdverm3 hours ago
    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
  - DemocracyFTW22 hours ago
    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.