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

321–330 of 516 posts

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

#321

Post by ATsch »

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…

I think, given a language that supports elegantly catching exceptions, it is inevitable that things like that will be written. And why not? The language makes them nice to write, which signals to users that it is something you should be using a lot.

I think the approach Go, Rust and others take there is the right way to go. By making panics annoying or even impossible to recover from in some cases, they ensure that they are only used for their intended purpose and are not abused as a general purpose control flow mechanism.

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

#322

Post by Koshkin »

zozbot234 wrote: post #295
Koshkin wrote: post #265

Earlier quoted context omitted.

Careful with lambdas, they are not without an overhead.

Lambda is designed to be a zero-overhead feature. In the worst case, it's the same as passing an additional void* ctx argument to a plain old function, which is the most common pattern in C/pre-lambda C++.

But it's not. A lambda is merely syntactic sugar for an object (a functional) and as such it can carry a state (the term is 'closure' in this case); depending on what is being captured, its creation can even involve a heap allocation.

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

#323

Post by gpderetta »

zozbot234 wrote: post #281
gpderetta wrote: post #271

Earlier quoted context omitted.

I agree that functions should specify in their signature wether and how they fail, but checked exceptions can do that. Additional call site syntax is indeed just noise. I strongly agree with David Abrahams[1] on this. A better solution would be noexcept regions were the compiler would statically guarantee that they can't be left via exceptional control flow. [1] https://forums.swift.org/t/on-the-proliferation-of-try-…

"noexcept" regions would be even noisier than the established pattern of non-fallible calls as the default and some lightweight syntax (such as '?' in Rust) to indicate fallibility. Sure, if literally all calls were fallible the '?' or equivalent would be redundant to call syntax, but everyone knows that this is not the case. And it's important that the failure-prone case be acknowledged as such.

You would use noexcept only around any code modifying an invariant you need to protect.

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

#324

Post by kllrnohj »

jerf wrote: post #113
ModernMech wrote: post #51

Earlier quoted context omitted.

This is the great strength and weakness of C++. Increasingly the answer to C++'s rough edges is "We don't do things that way anymore. Everyone does X now", where X is the hot new thing. RAII is the best example I can think of, where some people insist that no one would ever use the "new" and "delete" keywords anymore. Except for all the C++ devs that do, and all the C++ code that exists that does and must be maintain…

I kinda look to when the thing finally stabilizes as a sign as to how bad the problem was. For instance, Javascript front end was a nightmare for a long time, but it seems to have finally stabilized into a reasonable stable configuration with a couple of winners, some minor specialized choices, and the endless churn is now a minor sideshow instead of something that is changing the default choice every six months. The…

> it still seems like "best practices" on C++ are churning around 1.5-2 years, it's been happening for my entire career, and it's still happening

I have to disagree with this quite strongly. What "best practices" churn are you seeing? Your reference example of "don't use new & delete" (which I agree with) was a single best practice change that happened ~10 years ago. Similarly https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines is like 5-7 years old now, and afaik hasn't had any significant revisions?

The "churn" was really pre-C++11 to post-C++11. It was more like a python 3 moment than churn, other than it's taking a long, long time for code bases to catch up.

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

#325

Post by randyrand »

infogulch wrote: post #207
wvenable wrote: post #159

Earlier quoted context omitted.

> and 1% of your tasks fail That's a lot of failures. I'd question whether or not you should be using exceptions for something that happens 1% of the time all the time. Admittedly you might not have any choice in the matter if it's a dependency that is failing.

The "exceptions should be exceptional aka rare" line sounds aspirational, but I wonder how true it is if you survey the general landscape of actual libraries.

On top of that, you never know the context in which your users will call your library.

Are you encoding a single file on a local machine? Or 1000 files on some HPC 128-core machine?

Do we really want to be in a world where all libraries need to be written with and without exceptions since we can't know the context they'll be used in?

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

#326

Post by hashmash »

layer8 wrote: post #298
hashmash wrote: post #212

Earlier quoted context omitted.

Most of the software I write is designed to be fault-tolerant, and checked exceptions are fantastic way of detecting potential faults. The problem is that checking is baked into the exception definition instead of its usage. If I declare "throws NullPointerException", then this should mean I want it to be a checked exception. This should force the caller to catch the exception, or declare throwing it, or to simply th…

The distinction some Java programmers make (including myself) is to treat RuntimeExceptions as indicating interface contract violations (usually preconditions), or more generally, bugs. That is, whenever a RuntimeException occurs, it means that either the caller or the callee has a bug. When existing APIs use RuntimeExceptions to indicate any other error condition, they are wrapped/converted into a checked exception…

The problem that you outlined is a different one than whether or not exceptions are checked. The further an exception is thrown (call chain depth), the more context that gets lost. This can be fixed with more specialized exception types.

My example of declaring an NPE as checked isn't something I would actually encourage. It conveys very little context, and exceptions which extend RE should signal a bug in the code. I should have selected a better example.

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

#327

Post by JAlexoid »

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.

Adding features from literally every other language, just to create a mess - isn't really a selling point.

Right now, to learn C++ in a generic way, you need to learn pretty much all of programming paradigms and all of their variations - which is not a thing I would consider a plus.

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

#328

Post by Traster »

randyrand wrote: post #312
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…

The only way exceptions should be exceptional is that they should rarely be used in any code base. At best, the are a micro optimization that helps you a tiny bit in the success case. They should be used when standard return value errors are measured to be impacting perf (ie. exceedingly rarely). Unfortunately, C++ language authors made them basically a requirement for OOP and RAII. Imagine writing a parser. Can you…

Ok, I'll bite. Disclaimer: I'm not a software engineer, FPGA engineer by training. The use model I have in my mind is that my functions all work 99.999% of the time, but occasionally something happens where basically I want to throw up, I want the whole thing to collapse. Exceptions are great for me. I'm in an industry where "stop" is an okay solution in the rare occasion something goes wrong. So what's the alternative? I have to overload my return values annd then put in a load of special cases to propogate or return the exceptional cases.

I am aware there are functional languages that have other ways of dealing with this, or languages with things like optional values etc. But fundamentaly I like the idea that there's just a mechanism to just collapse, and collapse in a way that is traceable.

Having said that, my experience essentially does not involve catching exceptions, to me that's what is almost unthinkable (read: probably a bad hack). I guess my use case is not performance but separateing normal code function from catastrophic errors. Could you explain, do you think this is a fundamental mistake in the way I'm approaching this?

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

#329

Post by tremon »

randyrand wrote: post #312
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…

The only way exceptions should be exceptional is that they should rarely be used in any code base. At best, the are a micro optimization that helps you a tiny bit in the success case. They should be used when standard return value errors are measured to be impacting perf (ie. exceedingly rarely). Unfortunately, C++ language authors made them basically a requirement for OOP and RAII. Imagine writing a parser. Can you…

They should be used when standard return value errors are measured to be impacting perf (ie. exceedingly rarely)

I disagree with this. I think they should be used whenever "standard" return value error handling starts to obfuscate the normal operation (happy flow) of the code. This impact on developer performance happens a lot sooner than the measurable machine performance.

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

#330

Post by JAlexoid »

jcelerier wrote: post #292
JAlexoid wrote: post #142

Earlier quoted context omitted.

One of the reasons why I try to avoid C++ is that it's an unopinionated multi paradigm kitchen sink language. There are great uses and great features, but there are so many of them and everyone has their own opinions.... Even in this thread there's a clear subset of people who "adore" C++ exceptions

So interesting, to me a language being opinionated is the main reason to put it on the do-not-use bin. I strongly believe that the best way to develop is through embedded domain-specific languages adapted to individual problems, and opinionated languages are always way too limiting regarding that.

Your statement contradicts itself - you're against optionanted languages, but insert an opinionated language(DSL) into an unopinionated language.
Post reply on HN