5 ms·
> they claim that C++ exception handling produces "undefined" behavior (it doesn't), Exception safety (i.e. ensuring state is transactional) is hard in any lan
by dbaupp 8y ago
> they claim that C++ exception handling produces "undefined" behavior (it doesn't),
Exception safety (i.e. ensuring state is transactional) is hard in any language, but it's extra-hard in C++ where doing it incorrectly can lead to undefined behaviour rather than just an incorrect program. It's true that all of those sorts of problems with exceptions can occur just using normal `return`, but the hidden control flow of exceptions aggravates the problem by making it much harder to identify places of concern.
> Best of all, these very serious people, having written very sagacious emails banning random parts of C++ and intoning that horrible things happen if one allows non-local flow control, switch from their email clients to their editors and go on to write Python and Java! Somehow, exceptions are cripplingly unusable in C++ yet not worth writing home about when used in Python or Java.
This seems unreasonable. In general, people aren't nearly as demanding about things like performance for tasks they're solving with Python and Java as with C++. Additionally, I'm sure a significant chunk of those who dislike exceptions in C++ also dislike them elsewhere, but there's a variety of reasons that they're using any of those languages despite that (an inherited codebase, library support, ...).
> To wit: there were real performance and correctness problems with exceptions in early 1990s C++ compilers. These problems have been resolved for a very long time.
Clang, a C++ compiler, and LLVM, its optimizer back-end, don't use exceptions. While there are probably a variety of non-technical factors also coming into play, it seems hard to swallow that literal C++ compiler writers would entirely cargo-cult a major choice like this.
- quotemstr 8y agoThere's an element of Nissan Taleb's "Dictatorship of the Small Minority"[1] at work here. If you bring together a random group of C++ programmers, some of them will approve of exceptions and some of them will see exceptions as an abomination. The former group will grudgingly write non-exceptional code; the latter group will not write exceptional code (at least in C++). Consequently, the codebase ends up banning exceptions, the fact of which the anti-exception people use as evidence for more exception bans in other projects. This dynamic doesn't speak to the validity of the argument against exceptions. It just indicates that it's usually easiest, socially, to just appease the anti-exception people. [1] https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15#.z5ry4bucq https://medium.com/incerto/the-most-intolerant-wins-the-dict...
- adrianratnapala 8y agoIn this case though, the dynamic goes both ways. Programmers brought up on modern C++ will frequently be just as intransigent against error-return values and other alternatives to exceptions. In my own experience, exceptions are useful because real programmers can't be trusted to handle errors at all. So it is better to crash the program than to allow silent corruption. And exceptions are more politically palatable than assertions. But if the quality of your team AND processes are high enough you can expect errors will actually be handled, then it is easier to do that correctly without exceptions.
- quotemstr 8y agoI hope that reasonable people in both camps can agree that blatant contract violation and assertion failure should result in fail-fast instant death. It's a sad environment that bans assertions.