On Thursday, 23 August 2018 at 23:06:00 UTC, Ethan wrote:
Is that actually true, or would handling exceptions within the constructor allow one to initialise the object to an invalid state and thus still follow RAII paradigms correctly?
If you end up needing to check for that uninitialised state in all the other member functions for correctness (to avoid operating on invalid pointers/handles/…), that's a imho bastardisation of RAII that destroys most of the benefits.
Also, how do you inform the client code that something went wrong internally? Most likely, you'd want to construct the objects internally and pass them into the constructor to get around that; hence the composability argument.
The amount of bugs and pain I've had to deal with in production code because of throwing constructors makes me lean more towards Walter's viewpoint here.
What was the root cause of these issues?
Why can't RAII objects do the same if it performs operations it *knows* throw exceptions?
Apart from the above argument, this would require making all constructors implicitly nothrow to avoid degrading into faith-based programming.
— David
