Current hardware trends make C++ exceptions harder to justify • Hacker News Board

Re: Current hardware trends make C++ exceptions harder to justify

#131

Post by chippiewill » Tue, Feb 22, 2022, 7:31 PM UTC

CyberRabbi wrote: post #13

I am glad more people are raising the issue with C++ exceptions. Unfortunately I don’t think the argument made in this article is compelling enough. Bjarne is against replacing the current model and has written an entire article responding to various criticisms of the current model. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p194... In particular he has already responded to the efficiency argument with t…

Probably worth mentioning that while Bjarne is the creator of C++ and his opinion holds a lot of weight, he's also one of the few language creators who doesn't hold a BDFL hat (and hasn't held that kind of control for a very long time).

Re: Current hardware trends make C++ exceptions harder to justify

#132

Post by masklinn » Tue, Feb 22, 2022, 7:32 PM UTC

pjmlp wrote: post #109

mjw1007 wrote: post #79

Earlier quoted context omitted.

One of the motivating examples for exceptions, at the time when they were beginning to appear in mainstream languages like Ada, was to allow people to write arithmetic expressions using familiar notation, while still having a place to put an error handler for the overflow case. Perhaps the lesson of the last forty years or so is that this convenience wasn't worth adding such a heavyweight feature to the language, but…

C++ is the only language where exceptions are such an ideology war. All the other ones that have born with exceptions don't have this issue, including Ada.

I'm not sure that's true.

Exceptions are a big issue in Javascript, though mostly because they're absolutely terrible.

Whether to use exceptions or not is a common question in e.g. C#, and several APIs are duplicated to have both exception-based and values-based variants. And Python is oft criticised for using exceptions more than once every blue moon.

Re: Current hardware trends make C++ exceptions harder to justify

#133

Post by ncmncm » Tue, Feb 22, 2022, 7:33 PM UTC

erwincoumans wrote: post #111

worik wrote: post #31

Earlier quoted context omitted.

Why do you use C++ in those domains? Curious as to the decision criteria.

C is fine too. I pick a C++ subset that is closer to C than to full modern C++17. Full control over memory access, hardware access and execution. I haven't learned enough Rust yet, that could be fine too, but Rust lacks still many libraries in Robotics and Game development. What else do you suggest?

In other words, you pick exclusively the worst features of C++, and ignore all the actually useful, helpful features that enable you to write better code. If you just want C, use C.

Re: Current hardware trends make C++ exceptions harder to justify

#134

Post by mwcampbell » Tue, Feb 22, 2022, 7:34 PM UTC

kccqzy wrote: post #96

edflsafoiewq wrote: post #72

Earlier quoted context omitted.

My problems with Result/expected/etc 1. They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. 2. In particular, if a change causes a deeply nested function that used to always succeed to be able to error, the entire path up the call graph needs to get Resultified. 3. Since the caller must be aware of them, generic code generally has to be Result-aware too. 4. The…

> 2. In particular, if a change causes a deeply nested function that used to always succeed to be able to error, the entire path up the call graph needs to get Resultified. This is a pro not a con. It now shows clearly that all these function calls are now failable. Of course at higher levels you may have additional assumptions that you know won't make the low-level functions fail, and you are welcome not to change e…

> Panics do not need to be caught and handled. You can (and should) transform panics into abort.

I think this strong stance needs some justification, especially since it's not the default in Rust.

Re: Current hardware trends make C++ exceptions harder to justify

#135

Post by tneumann » Tue, Feb 22, 2022, 7:34 PM UTC

grandinj wrote: post #90

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on a profile, let alone become a problem. I think this paper started with a conclusion, and worked backwards to justify it.

I am the the original author, and trust me, I am describing a real world problem. I run massive parallel data processing tasks on machines with 128 cores, and unfortunately some of them produce errors deep within the processing pipeline. From a programming perspective exceptions would be ideal for that scenario, but they cause severe performance problems.

Just think about this: If you have a 100 cores, and 1% of your tasks fail, one core is constantly unwinding. And due to the global lock you quickly get a queue of single threaded unwinding tasks. And things become worse, we expect to have machine with 256 cores soon, and there it is even more dangerous to throw.

If you do not believe me look here: http://wg21.link/p0709 It lists quite a few applications that explicitly forbid exceptions due to performance concerns.

Re: Current hardware trends make C++ exceptions harder to justify

#136

Post by wvenable » Tue, Feb 22, 2022, 7:35 PM UTC

jstimpfle wrote: post #116

wvenable wrote: post #40

Earlier quoted context omitted.

Exceptions come naturally from the realization that you mostly have to propagate errors to where they can be suitably handled or logged. And all that propagation code heavily detracts from the meaning of the code when you are writing it or reading it. And messing up the propagation is a common source of issues (historically). With "exceptional" errors are are only 2 real recovery options: restart the operation or ter…

> Exceptions come naturally from the realization that you mostly have to propagate errors to where they can be suitably handled or logged. I agree of course that errors must be handled and logged as appropriate, but the implication that this has to happen by popping from the call stack is not justified at all.

Logging can be done but I can't see how you could handle errors.

If I'm processing 10 transactions and transaction 8 fails, needs to be retried a couple of times before being skipped for 9, I don't know how you'd do that other than going up the stack to where you're looping over the transaction list.

Re: Current hardware trends make C++ exceptions harder to justify

#137

Post by netr0ute » Tue, Feb 22, 2022, 7:35 PM UTC

henrydark wrote: post #93

grandinj wrote: post #90

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on a profile, let alone become a problem. I think this paper started with a conclusion, and worked backwards to justify it.

As per the piece, open 128 documents on a 128 core machine, and you'll see the difference.

How many people actually use a 128 core machine though? The absolute biggest AMD Threadripper you can get only has 64.

Re: Current hardware trends make C++ exceptions harder to justify

#138

Post by Koshkin » Tue, Feb 22, 2022, 7:36 PM UTC

pjmlp wrote: post #109

mjw1007 wrote: post #79

Earlier quoted context omitted.

One of the motivating examples for exceptions, at the time when they were beginning to appear in mainstream languages like Ada, was to allow people to write arithmetic expressions using familiar notation, while still having a place to put an error handler for the overflow case. Perhaps the lesson of the last forty years or so is that this convenience wasn't worth adding such a heavyweight feature to the language, but…

C++ is the only language where exceptions are such an ideology war. All the other ones that have born with exceptions don't have this issue, including Ada.

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

― Bjarne Stroustrup

Re: Current hardware trends make C++ exceptions harder to justify

#139

Post by pjmlp » Tue, Feb 22, 2022, 7:36 PM UTC

Thaxll wrote: post #56

Negitivefrags wrote: post #28

Earlier quoted context omitted.

We disable exceptions in video games due to lock contention when throwing exceptions on multiple threads in high core count situations? No. We disable exceptions in video games for dumb historical reasons that no longer apply.

Dumb? https://www.youtube.com/watch?v=GC4cp4U2f2E

Depends on the point of view.

https://youtu.be/6hC9IxqdDDw

Re: Current hardware trends make C++ exceptions harder to justify

#140

Post by throw10920 » Tue, Feb 22, 2022, 7:37 PM UTC

john567 wrote: post #27

Why do we need to have ambient control flow? This is what exception handling is, it's a hidden control flow. I don't use them. I just create an error type and pass that around. The only legitimate exception I will accept is when you access invalid memory. That's a special case and depending on the environment something extraordinary must happen. But exceptions and exception handling just creates annoying code. It doe…

> Why do we need to have ambient control flow?

Because, properly-used, it saves you a lot of effort.

Returning an error type unwinds the stack. If I have a low-level computation that has a number of error cases, and I want the high-level code to intelligently handle some of those error cases and continue processing, that's not doable using return values. Error codes bind the decision of which error-recovery strategy to take (which is only present at a high level) with the details of that strategy (which is only present at a low level).

As a trivial, obviously-fake example - if I have a high-level GUI library that makes use of a low-level division function, I might occasionally divide by zero. Depending on what the GUI library was doing, I might want my divideBy(x, y) function to return 0, 1, the first argument, the second argument, or not return anything because that section of the code will be completely aborted.

Without ambient control flow, if you just have return values, you have to check the return value for every single division operation you perform - and you'll have to re-implement code paths where a division operation failed.

What if you have a long-running operation? If you return an error value when that operation happens, but it turns out the nature of the operation allows you to ignore that error and continue, you'll have to re-start the entire computation. If you hard-code the lower-level logic to ignore errors and continue, then you'll also end up ignoring errors that you really shouldn't.

Error types do not solve these problems - in fact, they require that you duplicate lots of code to, say, make multiple variants of a library that are identical except when it comes to error-handling - or just cause your applications to lose lots of error-handling nuance and bail early on lots of exceptional circumstances that could be recovered from.