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

331–340 of 516 posts

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

#331

Post by kllrnohj »

mcguire wrote: post #177
dtech wrote: post #170

Earlier quoted context omitted.

Java's checked exceptions are generally regarded as a mistake. There's a reason no other languages has them, and newer JVM languages (Groovy, Clojure, Scala, Kotlin) treat all exceptions as runtime. Anders Hejlsberg (creator of Delphi, C# and Typescript) also has an excellent article on their problems [1]. In modern Java I see nearly only runtime exceptions used, especially because that's necessary for most Java 8+ l…

" Java's checked exceptions are generally regarded as a mistake. " By people who do not want to believe that errors are part of a system's API and prefer to just write the happy path and let any exception kill the process. And who don't mind getting called at 2:00 am because a dependency buried deep in a subsystem threw an exception that you'd never heard of before.

Errors are part of the system's API, but Java's checked exceptions aren't really that.

Case in point, the many checked exceptions in the Java standard library that are never, ever thrown. Ever. Such as ByteArrayOutputStream#close(). In fact the docs on that method even say it doesn't do anything, and won't throw an exception. But there's still a checked exception that you have to handle, because it came from the interface.

Which is part of why checked exceptions are a mistake. If Java wasn't so aggressively OOP, then maybe there's a good idea there. Like maybe checked exceptions in C++ would work, as you're not relying (as much) on inheritance to provide common functionality. But as soon as interfaces & anonymous types (eg, lambdas) enter the scene, it starts falling over.

Also in terms of API design, checked exceptions are quite limiting. Especially when working with asynchronous APIs, as checked exceptions are inherently coupled to synchronous calling conventions.

And there's also then the problem of not a whole lot of your code base is an "API surface" (hopefully anyway), and it's really vague how a middle layer should handle checked exceptions. Just propagate everything? But that's a maintenance disaster & leaks all sorts of implementation details. Just convert everything to a single type? Well now you can't catch specific errors as easily.

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

#332

Post by randyrand »

Traster wrote: post #328
randyrand wrote: post #312

Earlier quoted context omitted.

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 alternati…

> I have to overload my return values annd then put in a load of special cases to propogate or return the exceptional cases.

Yes + syntactic sugar. Propagating an error up can and should be a single character of code.

> collapse in a way that is traceable.

Zig supports "error traces" (note, not stack traces) by default, since they have a single common way of reporting errors and a smart compiler.

> I like the idea that there's just a mechanism to just collapse,

Go uses Panic + Recover.

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

#333

Post by freedomben »

lanstin wrote: post #285
ncmncm wrote: post #167

Earlier quoted context omitted.

More people start using C++ professionally in any given week that the sum total paid to code Rust. Rust is not "displacing" C++ anywhere beyond the HN echo chamber.

We've talked about Rust in my monthly beering meetings with other programmers, so it's definitely gaining mindshare to some extend. And it's being prepped for Linux kernel inclusion. Once that lands it will be pretty respectable.

Do many people in the meetings comment about the functional programming feature of rust? That to me is one of the greatest benefits as functional patterns are (at least were) harder in C++ and were definitely less common (which makes code harder for others to understand).

In your sample of C++ people, is there much interest in functional programming?

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

#334

Post by JAlexoid »

zozbot234 wrote: post #195
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

There's no such thing as an "unopinionated" kitchen sink language. Language features have all sorts of unforeseen interactions that must be handled somehow, and good high-level design is needed to ensure that the interactions are sensible.

We're in the context of such unforeseen interaction.(Ironic, isn't it)

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

#335

Post by [deleted] »

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.

[deleted]

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

#336

Post by TheMonarchist »

jcelerier wrote: post #286
foldr wrote: post #262

Earlier quoted context omitted.

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.

Not in C++ I believe ?

https://en.cppreference.com/w/cpp/io/basic_ios/exceptions

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

#337

Post by randyrand »

tremon wrote: post #329
randyrand wrote: post #312

Earlier quoted context omitted.

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.

It should not obfuscate the happy path.

In rust, propagating an error up is as easy as adding a '?' after the function call.

  fn read() -> Result {
      let f = File::open("hello.txt")?; // propgate up? 
      let s = f.read_to_string(&mut s)?; // propgate up? 
      Ok(s)
  }

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

#338

Post by kllrnohj »

netr0ute wrote: post #137
henrydark wrote: post #93

Earlier quoted context omitted.

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.

That seems like an awfully short sighted argument. Less than 20 years ago we were all using single-core CPUs. Now most of us have at least 6 cores if not more in a battery powered handheld device that we don't even expect to do much compute work on (aka, smartphones). And 8-16 cores w/ SMT are not an unusual consumer laptop/desktop configuration.

The articles suggestion that it's only a matter of time for 128+ core CPUs to be common, at least in the server space, is probably the least contentious argument it makes?

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

#339

Post by throwuxiytayq »

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.

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++?

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

#340

Post by michaelnik »

CJefferson wrote: post #189
ziml77 wrote: post #34

I find this analysis strange. Yes, C++ does need ergonomic ways to return an error without dynamic allocation (Rust's magic of ? combined with the From/Into traits is nice), but I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions. It's not really an exceptional circumstance at that point.

Why am I "not supposed to use exceptions"? I don't understand why exception should be used when errors occur occasionally, or when they occur 50,000/sec. They are a control flow method for when errors occur.

I'd add a (major) inconvenience is problem investigation, often exceptions point you to root cause and all you need it to break on the first exception (think after running big codebase, for an 1h just to get where problem is), but if they are thrown willy-nilly this debugging strategy is MUCH less convenient...
Post reply on HN