Exception throwing is the goto of 21st century. The article's examples aren't the worst, it's common seeing exceptions for business rules in Java/.NET land.
Wat? I thought callbacks are the goto of 21st century.
Why should I have written ZeroMQ in C, not C++ (2012)
71–80 of 147 posts
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#72This seems to be a failure to understand when exceptions and when error codes are to be used. I'm just starting a big infrastructure project that needs to be high uptime and distributed across a large number of machines, and I'm doing it in C++ because I know I'd never get it working in anything else.
Let's take one specific example -- connecting to a remote host. The loop that goes through the DNS returned IP numbers uses local error codes to try each in turn until one is accepted. If none are accepted it throws an exception so that the higher level application code can decide what to do about the connect failure. The exception ensures that all resources are properly cleaned on the way through.
The exception is used to guarantee that resources are properly de-allocated on the way back up to where the error needs to handled as it cannot be handled locally, probably not in the function that kicked off the connect attempt either, but there's no local exceptions to handle the case where the error is handled locally.
The use of the exception is more like a ROLLBACK on a database transaction together with error reporting -- it helps ensure correctness by backing out properly changes in state that were kicked off by the connect attempt. When the exception is caught the program state is exactly as it was when the connect attempt was first tried so we know we have good clean state to make another attempt or to move on and do something else. Backing out all of these other state changes is really hard when an error code needs to be handled non-locally -- and it's this non-local handling of errors that's so hard and error prone without exceptions.
So if you're only ever using error codes you'll far too easily make mistakes when the error needs to be handled non-locally, and if you're only ever using exceptions then it's going to be real ugly when the error is handled locally.
You need to use both if you want clean code that is going to work reliably (or you need massive engineering resources to fix all of the bugs you'll end up with).
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#73As usual, this guy doesn't understand how to use C++. Nobody with any significant C++ experience puts error generating code in constructors. Once I saw that I stopped reading.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#74Re: Why should I have written ZeroMQ in C, not C++ (2012)
#75Interesting article. So, more confirmation C++ is inferior for writing predictable or high performance applications. I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game. Zero-cost abstractions plus solving C++'s specific problems, painless C FFI, and compilation to C (or LLVM) to leverage their compilers. Might make a nice combo. I doubt we'll see much t…
Nope. The author was just clueless.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#76Earlier quoted context omitted.
And so I will continue to avoid C++ because I'm not a master and will not avoid the many pitfals, and I want to get things done, not become a master of C++.
Actually avoiding C++ pitfalls is not that difficult as most of them come from C: manual memory management, macros, varargs, unsafe casts. In fact C++ provides safe alternatives to many of the unsafe C constructs, so if you stick to them you are fine.
C++ not only fails to hide the above-mentioned C pitfalls but adds entire classes of pitfalls of its own. Just a few examples:
* undecidable grammar: http://yosefk.com/c++fqa/defective.html#defect-2
* const inside containers: http://yosefk.com/c++fqa/const.html#fqa-18.1
* template error messages http://yosefk.com/c++fqa/templates.html#fqa-35.17
C is often nicer than C++ because it's simpler: it only has the C pitfalls not the combination of C & C++ pitfalls that plague C++.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#77From my experience, if you need to write many exception handlers then you have a problem in your design as you are using exceptions where you should have used explicit control flow. There is nothing fundamentally wrong with the exceptions and they are used in most modern languages, not only C++.
I completely agree; the entire time I'm reading this I couldn't help but feel this was misunderstanding the use of exceptions.
The stated design goal is that the project "never fail and never exhibit undefined behaviour" yet exceptions are exactly for undefined behavior. If you can't allocate memory, if your function is called with arguments that it cannot possibly interpret, or that a fully expected network connection has failed and cannot recover. Those are exceptions. For all your defined behaviors, you can control just as described in the article without exceptions.
There is clearly too many exceptions (and handlers) in the first case and way too few in the second case.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#78Earlier quoted context omitted.
Actually avoiding C++ pitfalls is not that difficult as most of them come from C: manual memory management, macros, varargs, unsafe casts. In fact C++ provides safe alternatives to many of the unsafe C constructs, so if you stick to them you are fine.
The pitfalls of C++ that I've seen are mostly the things people build with the safe alternatives.
Could you give an example?
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#79Earlier quoted context omitted.
yeah go/rust error handling is great. Much better than exceptions which make the code hard to read since you can't easily predict where is the flow going to jump. And the multiple-return is very convenient in this case too. Also, with Go's approach you have to either explicitly ignore the error or deal with it.
My problem with Go (and I love the language a lot) is that a lot of my error handling is "stop execution in the function and bubble the error up", which results in my code being littered with if err != nil { return err }, which is a bit annoying. If I'm doing something wrong here I'd love to know it.
That's exactly why exceptions were invented. They aren't really as magical and hard to understand as the parent poster seems to think. In a theoretical sense, exceptions just do if err != nil { return err } on every call automatically.
I feel like so many developers have been so damaged by Java's approach to exception handling that, of course, error codes seem simpler by comparison. I can't help by feel the recent push-back against exceptions is a step backwards in many situations. A whole generation of developers will have to re-learn the pain that lead to the development of exceptions in the first place.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#80Sometime in the future: "Why I should have written nanomsg in Rust, not C".
If you read part II (the link to it is near the end of the post), you see that one of the things he wanted was intrusive linked lists. From what I have read so far, implementing intrusive lists is not easy in Rust. (If you know of a working intrusive doubly linked list implementation in Rust 1.0 that does not invoke undefined behavior, please tell me; I'd like to know how it should be done.)
He could write his own link list template that only worked with LinkedListNode objects; anything you want to put in the list must inherit from LinkedListNode, which would keep the next/prev pointers. Seems like that would be the best of both worlds.