Author 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.
You 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.
It'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().
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.