Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Current hardware trends make C++ exceptions harder to justify

open-std.org

Post reply on HN
Print view View original

261–270 of 516 posts

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

#261

Post by lanstin »

wvenable wrote: post #168
zozbot234 wrote: post #86

Earlier quoted context omitted.

> They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. This is not "noise" but needed information. A function that can error out should not have the same signature as one that will never return an error. Similarly, call-site special syntax (like '?' in Rust) helps address the concerns raised by hidden control flow. > Since the caller must be aware of them, gener…

> A function that can error out should not have the same signature as one that will never return an error. Functions that never fail are pretty rare compared to ones that do. It's easier to just assume that all functions can fail. Mentally it's a much simpler model.

This post is the saddest thing I have ever read in computing. So much power comes about (on the CPU, in the call stack) by being able to assume that things proceed with mathematical tractable properties, as computable functions, plain old general recursion. Distributed things, sure, you have to have protocols and so one to regain the determinism, and even then perfection is no longer achievable, but within your big FSM of CPU/memory/disk, it's all pre-calculated in some platonic ideal of computable, recursively enumerable Platonic world of simplicity and knowability about which we can reason.

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

#262

Post by foldr »

whatshisface wrote: post #259
shrimpx wrote: post #255

Earlier quoted context omitted.

Your opinion being that you should not use exceptions in that type of case. In which cases should you use exceptions?

When something happens that violates your assumptions about your own program's behavior, throwing it into a state where it doesn't know what happens next. Kind of like a panic.

This would mean that attempting to open a file that doesn't exist shouldn't throw an exception. But that is exactly what it does in the standard libraries of many languages with exceptions.

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

#263

Post by lanstin »

musingsole wrote: post #143
zozbot234 wrote: post #86

Earlier quoted context omitted.

> They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. This is not "noise" but needed information. A function that can error out should not have the same signature as one that will never return an error. Similarly, call-site special syntax (like '?' in Rust) helps address the concerns raised by hidden control flow. > Since the caller must be aware of them, gener…

> one that will never return an error Code that is error-safe is so rare. Why adopt a pattern that elevates the normal case ("here be errors") to information you have to disclose at every turn?

Oh my, this sentiment is common. Errors can't happen inside a Turing machine. The errors are just when you step outside the process to interact with externalities. Computations should be thought of as having errors in it them, any more than the integers do. Network or disk calls maybe have all sorts of things happen. You have to think about the failures whenever you have succumbed to reaching outside of your call stack for answers. Because those remote or shared by other processes resources might not reach the same level of certainty, and your perfect code might or might not need the answers or be able to work around their lack.

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

#264

Post by wvenable »

lanstin wrote: post #261
wvenable wrote: post #168

Earlier quoted context omitted.

> A function that can error out should not have the same signature as one that will never return an error. Functions that never fail are pretty rare compared to ones that do. It's easier to just assume that all functions can fail. Mentally it's a much simpler model.

This post is the saddest thing I have ever read in computing. So much power comes about (on the CPU, in the call stack) by being able to assume that things proceed with mathematical tractable properties, as computable functions, plain old general recursion. Distributed things, sure, you have to have protocols and so one to regain the determinism, and even then perfection is no longer achievable, but within your big F…

One errant cosmic particle and all determinism goes out the door as well.

The story of computing is not one of mathematics, it's of people and it's of change. Software is about codifying decisions and without perfect knowledge of the universe those decisions are always going to be wrong in some way. And that's even without introducing the infallibility of programmers. Errors are simply part of the process.

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

#265

Post by Koshkin »

TillE wrote: post #200
ncmncm wrote: post #133

Earlier quoted context omitted.

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.

"Modern C++ bad" is such a weird HN meme, fortunately it's not an opinion I see a lot elsewhere. Old C++ was awful, the new stuff makes it actually usable. Personally I like how even in embedded code where you don't want to include the standard library, you can still efficiently use language constructs like constexpr, lambdas, etc.

Careful with lambdas, they are not without an overhead.

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

#266

Post by olvy0 »

downut wrote: post #165
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.

In 30 years of c++ I've never seen error checking + throw in a tight numeric intensive loop like this. Sure, somebody could do it. I'd have a chat with a coworker who wrote something like that. I only use exceptions for cleanly unwinding the stack when an unrecoverable error occurs. I design and implement my code so that is rare .

Totally agree, I do the same, up to and including having a chat with a coworker who wrote code like that. I just did that last week, in fact.

Code that uses exceptions like this is a code smell, especially when performance is important. Using exceptions as control flow instead of if/loops is not a good design, IMO.

Note that this is in C++. I consider this style of writing not idiomatic, despite the STL doing it. I use either error return codes or std::optional (itself having a set of problems but IMO better than exceptions).

I'm more willing to accept this kind of code in Java, where it's more or less idiomatic. Less so in C#, where the tendency in the last 15 years has been to use the Try__ method instead of throwing exceptions.

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

#267

Post by NoSorryCannot »

JoeAltmaier wrote: post #213
gumby wrote: post #191

I find this paper quite unconvincing. Exceptions are exceptional so in principle it doesn't matter (within reason) how long it takes to throw one as long as it costs nothing not to do so. So measuring the cost of repeated throws IMHO doesn't cast light on any useful case, and the approaches that add runtime cost for the path not taken, even Herb Sutter's, are not acceptable. His code transformation example is simply…

But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. I deplore that - its side-effects writ large. But those that use it, find it reasonable and sensible. It's become hard to distinguish right and wrong when it comes to CPU optimization. Different versions of the 'same' CPU can have wildly different sweet spots.

Exceptions have some of the properties of a discriminated union, which is why they're used this way. Sometimes it seems parsimonious compared to the alternatives.

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

#268

Post by erwincoumans »

TillE wrote: post #200
ncmncm wrote: post #133

Earlier quoted context omitted.

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.

"Modern C++ bad" is such a weird HN meme, fortunately it's not an opinion I see a lot elsewhere. Old C++ was awful, the new stuff makes it actually usable. Personally I like how even in embedded code where you don't want to include the standard library, you can still efficiently use language constructs like constexpr, lambdas, etc.

I didn't mean to say "modern C++ is bad", but I'd prefer a small subset that I can be sure no surprises happen: no hidden memory allocations and such. In fact, we use modern C++ and Eigen and CppAd Codegen in some of our projects: the generated C code by tracing a full sim step is about 5 times faster, likely due to no memory allocations and cache friendly memory access.

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

#269

Post by Jtsummers »

talaketu wrote: post #246
gumby wrote: post #191

I find this paper quite unconvincing. Exceptions are exceptional so in principle it doesn't matter (within reason) how long it takes to throw one as long as it costs nothing not to do so. So measuring the cost of repeated throws IMHO doesn't cast light on any useful case, and the approaches that add runtime cost for the path not taken, even Herb Sutter's, are not acceptable. His code transformation example is simply…

"exceptions are exceptional" means what?

Exceptional means "unusual" (by the dictionary definition). In theory, exceptions should be thrown in in exceptional (rare, unusual) circumstances. Things like running out of memory, or dealing with random poorly constructed data inputs are reasonable circumstances to use exceptions. However, if your input is consistently mangled, an exception may not be the appropriate way to handle it since it becomes a normal thing (if for no other reason than performance) depending on how you want to handle the problem and whether that performance cost is worth it.

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

#270

Post by Koshkin »

synergy20 wrote: post #32
rossmohax wrote: post #20

If not exception, then how to fail constructor?

you can still set a static flag or something in ctor then check it, but you can't do anything about dtor indeed if you need throw there.

Except you are not supposed to throw in a destructor.
Post reply on HN