To a great extent C++ exceptions exist and are the way they are because you can't return an error from a constructor.
On the other hand, constructors don’t allow returning an exception because C++ has exceptions.
I mean .. yes, but easy multiple-value-return unpacking is also a fairly new feature. Back in the 90s you had one (1) lvalue. Making the "return (thing, error)" pattern miserable to use.
I was going to say that such an alternative history C++ could have had MRVs earlier, or even sum types... but apparently exceptions were added a decade after constructors (if we draw that back to the original "C with classes").
So yeah, you're right that constructors led to exceptions, unless the designers of C++ had been willing to go back to the drawing board and entirely redo constructors.
Re:The Cost of Exception Handling
by chrisseaton on Saturday November 12, 2022 @07:43AM
(#33572510)
> constructors don’t allow returning an error because C++ has exceptions
Didn't constructors (1979) come before exceptions (1986)? So no that's not the case.
Yes, I didn't originally know that (I thought constructors and exceptions would have been co-implemented and didn't consider that faillible ctors would have been outright impossible for a decade), and found out after pjc50's reply: https://news.ycombinator.com/item?id=33572348
Re:The Cost of Exception Handling
by chrisseaton on Saturday November 12, 2022 @09:45AM
(#33573527)
People used to use a flag in objects to say 'invalid because constructor failed', or make the constructor infallible, and have a separated initialise method which could return an error code.
So a better comparison would be: let construct() return a bool, an do manual error handling if it returns false. I'm pretty sure, the compiler will generate much worse code in this case.