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

371–380 of 516 posts

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

#371

Post by saurik »

exdsq wrote: post #150
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…

An FYI that Monads are useful for removing that (left, right) boilerplate from composed functions. This was the issue I had where they finally clicked for me.

Once you are using monads you are now doing the thing that person hates, though: removing the control flow from the code (as it got moved into the monad); really the syntax for exceptions is nothing more than a hardcoded-into-the-language error monad.

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

#372

Post by talaketu »

Jtsummers wrote: post #269
talaketu wrote: post #246

Earlier quoted context omitted.

"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 thin…

The primary definition (OED) is "forming an exception", which is why I think this cliche is a tautology ("exceptions are for forming an exception") that does nothing to guide me on whether an exception is appropriate in a given case.

Btw, we don't say "exceptions are for infrequent conditions", because that's not what they're for.

I quite like the etymological "taken out", because it carries a notion of special handling - a control flow aspect that is the main point of using them.

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

#373

Post by exdsq »

saurik wrote: post #371
exdsq wrote: post #150

Earlier quoted context omitted.

An FYI that Monads are useful for removing that (left, right) boilerplate from composed functions. This was the issue I had where they finally clicked for me.

Once you are using monads you are now doing the thing that person hates, though: removing the control flow from the code (as it got moved into the monad); really the syntax for exceptions is nothing more than a hardcoded-into-the-language error monad.

That's very fair, good point.

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

#374

Post by TheMonarchist »

aeldidi wrote: post #230
GnarfGnarf wrote: post #155

I manage 1.2MLOC C++ developed over 25 years. I am pleased to say we never had to use exceptions. Just check the return value.

How do you guys handle using other libraries? Everything I can see uses stuff like std::vector and the like at API boundaries, and I'm not aware of a way to construct an std::vector without throwing an exception.

> I'm not aware of a way to construct an std::vector without throwing an exception.

You use an allocator with enough pool for whatever you need to do and avoid out of bounds access.

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

#375

Post by snvsn »

josephg wrote: post #257
JoeAltmaier wrote: post #213

Earlier quoted context omitted.

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.

> But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. The problem isn’t that C++ exceptions are slow when used the way the compiler expects. The problem is a mismatch between how C++ expects you to use the feature, and how people are actually using the feature. I can’t find the story now, but I read about this happening with Ruby on Rails. Someone dug i…

Twitter's Ruby on Rails problem that the parent mentions - @26:30 https://youtu.be/LjFM8vw3pbU?t=1591

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

#376

Post by renox »

Koshkin wrote: post #355
throwuxiytayq wrote: post #339

Earlier quoted context omitted.

But it's not reasonable, sensible or performant. Thankfully, I've never seen anyone abuse exceptions like that in C# or any other language, is it really a thing in C++?

Fortunately, it is not. As this discussion shows, people more tend to avoid exceptions for various reasons (both good and bad) than to abuse them.

I wish unfortunately that's not my experience at work one developer used exception as a control flow with the excuse that it was on a non performance critical part of the code.. Annoyed me very much as it made gdb's 'catch throw' useless. So I reimplemented this code and the result was easier to read IMHO but of course I'm biased..

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

#377

Post by forrestthewoods »

ncmncm wrote: post #172
forrestthewoods wrote: post #10

> Nevertheless the overhead is so high that std::expected is not a good general purpose replacement for traditional exceptions. This is basically the path Rust has chosen. I’m curious if it’s _actually_ too slow for C++. I feel like the answer must be no.

It is always easy to find places where performance doesn't matter, and even Python is fast enough, including startup code in programs where performance otherwise does matter. You cannot draw useful inferences from those cases.

I would also strongly argue you can’t draw useful inferences from do_fib.

To rephrase it another way. In how many contexts is std::expect insufficient? It’s easy to find places where nothing short of hand rolled SIMD is fast enough. You cannot draw useful inferences from those cases.

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

#378

Post by josephg »

snvsn wrote: post #375
josephg wrote: post #257

Earlier quoted context omitted.

> But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. The problem isn’t that C++ exceptions are slow when used the way the compiler expects. The problem is a mismatch between how C++ expects you to use the feature, and how people are actually using the feature. I can’t find the story now, but I read about this happening with Ruby on Rails. Someone dug i…

Twitter's Ruby on Rails problem that the parent mentions - @26:30 https://youtu.be/LjFM8vw3pbU?t=1591

Thats the one - thankyou! Its interesting that google doesn't index the transcript of youtube talks.

Great detail I'd forgotten: At the time twitter took 460ms of compute to process each request. Almost all the CPU time was in bcopy, constructing the big string backtraces for exceptions (that were then being immediately discarded).

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

#379

Post by patrick451 »

pavon wrote: post #287
talaketu wrote: post #246

Earlier quoted context omitted.

"exceptions are exceptional" means what?

In C++ the convention is that exceptions shouldn't be used for things you expect to happen in the normal execution of the program, in a way that would harm performance. For example, it is better to explicitly check if an item is in a map than to rely on exception handling to branch to the case where the item doesn't exist. Generating an exception for FileNotFound would be fine for a single file selected by the user i…

I'm not really a fan of this pattern in python. As far as I can tell, it's all done in the name of duck typing: if the returned object appears to have the right property, that's good enough. But the problem comes when take that object and pass it on to some other function. It may have appeared like a duck to you, but 10 functions later, it's slightly off and you get a difficult to understand TypeError or AttributeError.

Where I do think this pattern makes sense is in trying to use system resources. Checking that a file exists or a process is alive before deleting or killing it is a recipe for difficult to track down Time of Check to Time of Use bugs. I'm curious if you think this is also an anti-pattern in c++ and if so, how you properly deal with the TOCTU race conditions?

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

#380

Post by ModernMech »

MauranKilom wrote: post #198
JAlexoid wrote: post #146

Earlier quoted context omitted.

Adding more and more features isn't necessarily an "improvement".

Sure, but that in itself is also not an argument. The space of programming languages in general is moving forward and languages keep adding more (usually higher-level) features. C++ is mostly trying to keep up.

Fred Brooks put it this way:

  "I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."
IMO C++ does not have conceptual integrity.
Post reply on HN