4 ms·

Except that you've still got to construct an object (because that's how constructors work), you're just signalling that it's an unusable one. Let's say your ob

Except that you've still got to construct an object (because that's how constructors work), you're just signalling that it's an unusable one. Let's say your object is going to contain another object that wraps a file, but constructing that file wrapper fails because the file doesn't exist. You are forced to construct your object, so you are forced to have something to put there. Maybe it's a dummy, maybe you can 'null it in some way', but it's immediately not as ergonomic. You also then have to either rely on the caller to not use the failed constructed object, or put a check in every method call checking for 'valid'.

mehrdadn 7y ago
Did I say it would be "ergonomic"? You're deliberately refusing to use the correct tool for the job; of course the next-best thing is going to be "not as ergonomic". Is that surprising? It was never "ergonomic" in C to begin with. You had to check status codes and manually allocate and deallocate and construct and destroy everything everywhere. Now we have a language here that automates a ton of this for you, and gives you better tools. It also lets you avoid the individual tools you don't like, while letting you use the others, and while letting you fall back to your old style entirely whenever you prefer, and you're still complaining about it? What are you even complaining about? If you think it's better to have everything to be difficult instead of some things, then just stick with C. There's no point having a pointless argument with me about it.