> You can't really just avoid language features like that.
As jcranmer points out, forgoing C++ exceptions is literally written policy for the browser you are likely reading this with right now. And no, you don't give up std.
C++ exceptions have been a misfeature since inception.
- Error flag in the class (not a good solution, though, as others have noted)
- Factory function that returns a smart pointer, or null on error.
- Just ensure your constructor never fails. (This probably means aborting on allocation failure. In practice that’s usually fine, depending on application.)
This is how you get the equivalent of `if err != nil { return err; }` everywhere in your codebase. We've already come to the conclusion that this pattern is terrible.
What you really need is to separate object allocation from construction. But then you're adopting an object model that C++ just doesn't support.
It sucks versus Foo() { if(...) throw whatever; }.
It needs more code (check for constructed() every time, and if you forget to checking it you've introduced a bug), and is less performant (since you will have one additional branch in the "if(constructed())" mandatory check.
The ‘error’ member variable would take an additional space in the object that otherwise could be as small as a byte. C++ is carefully designed to avoid unnecessary overhead.
As jcranmer points out, forgoing C++ exceptions is literally written policy for the browser you are likely reading this with right now. And no, you don't give up std.
C++ exceptions have been a misfeature since inception.