Why should I have written ZeroMQ in C, not C++ (2012)

It seems all too often we (coders) are encouraged to think of errors as these exceptional things that happen rarely; deserving only of a few cursory preventative treatments to the code -- or worse, treated as something only to be fixed lazily, as bugs and crashes surface during testing. Indeed -- this philosophy is ingrained into a significant percentage (if not the majority) of the programming languages we use! On the contrary, I believe we should expect to spend the…

1. That "C equivalent" for error handling is not an equivalent at all. If one could handle the error in the same function then there is no reason to throw. The "C equivalent" is returning an error code, which has other problems. 2. One can handle errors in initialization without exceptions and half-initialized objects: Make your constructor private and expose a static member function that returns an optional<T> (where T is the given class). 3. Throwing in destructors is not…

Read this paper before and don't buy it. // c++ if (condition1) throw my_exception1 (); you throw an exception because you can't handle it locally. But then he says // C if (condition1) handle_exception1 (); so if it can be handled locally in C it can also be in C++, so why throw anything? Also, and I'm not a C++ guy (a little exposure many years ago) so someone correct me, but if you look at part 2 of this…

This actually sounds like an argument for why he should've used a smaller subset (or different) of C++. For example: make all constructors private and empty and use public static factory methods for manufacturing new instances. Now the factory can fail, and return an error to boot. Similarly, ditch C++ exceptions and introduce the notion of a status object that methods return. You always have the option of C-style semantics without dumping the genuine advantages C++ brings. In terms of…