Constructors Shouldn't Throw

3 pointsposted 6 hours ago
by jcbhmr

12 Comments

quuxplusone

21 minutes 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).

MiroslavPokorny

3 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.

x-complexity

2 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.

AnimalMuppet

5 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.

verdverm

3 hours ago

neither should destructors, my first internship was at Bloomberg and I put a BIG into a crash loop with this

quietbritishjim

2 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.

verdverm

2 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

DemocracyFTW2

3 hours ago

> Constructors Shouldn't Throw

wrong

verdverm

3 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.

stevekemp

2 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.

verdverm

2 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

DemocracyFTW2

an hour 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.