3 ms·
90% of this thread isn't addressing his core point, which is that even if you use C++ without exceptions, constructors and destructors still make it hard to be
by gruseom 15y ago
90% of this thread isn't addressing his core point, which is that even if you use C++ without exceptions, constructors and destructors still make it hard to be strict about error handling, and the extra complexity isn't worth it for projects like his.
Fine to disagree, but respond to the point. So far the relevant objections I've seen are: (a) you shouldn't do anything in a constructor that might fail; and (b) destructors can't fail. Weak. Is there a good counterargument? To be precise: why is the OP wrong to say that, to be strict about error handling, his C++ needs to look like the block of code that follows the sentence, "There's a new 'semi-terminated' state" in the article?
(As for most of the comments, which boil down to "OP is ignorant of basic things about C++ and programming", come on you guys, how likely is that? Who's more likely displaying ignorance here?)
- pestaa 15y agoAuthor went from constructors+exceptions to init_foobar()+return value for error handling. When you misuse exceptions, they become unmanagable nightmare, which I believe would have happened with 0MQ. And throwing exceptions in constructors is one really good way to misuse them. And ranting about it seems like ignorance to me, but that's beside the point. For me, checking return values is just as, if not more, tedious than catching some exceptions. Return values should be used to guide the flow of the program state (IMHO), and exceptions represent invalid states.
- gruseom 15y agoYou still haven't responded to his point, which is that to deal with the reality that constructors and destructors can fail, he ended up having to write more complex code than he would in C. (Specifically, the code in the passage I cited, which turns each object into a little state machine.) Saying "just make those things not fail" is no answer at all. So, to repeat: how could he meet his error-handling goals in C++ without handling object construction/destruction in that state machine style? I have no opinion about this, but given that it's the point of the article, that's what people should be addressing.
- pestaa 15y agoIt's not that constructors/destructors can fail, it's about the conscious decision when you make them to. If you choose not to use exceptions at all, you can prevent improper state before object construction, just like you would in C's init_foobar().