4 ms·
> 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
by topspin 8y ago
> 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.
- Koshkin 8y agoThrowing an exception is the only sensible way for a constructor to signal a failure.
- speedplane 8y agoHow about this: class Foo { void Foo() { this.error = true/false; } bool constructed() { return this.error } }
- dymk 8y agoThis 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.
- jcelerier 8y agoIt 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.
- Koshkin 8y agoThe ‘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.
- iainmerrick 8y agoExceptions take space.
- iainmerrick 8y agoNot at all, there are several other ways: - 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.)