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

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

#511

Post by randyrand » Mon, Feb 28, 2022, 5:46 PM UTC

kllrnohj wrote: post #502

randyrand wrote: post #487

Earlier quoted context omitted.

Are you sure? Single threaded 18-16ms (boost::LEAF) vs 19-23ms (exceptions) A better comparison is found here: https://lordsoftech.com/programming/error-codes-are-far-slow... > TL;DR On modern 64-bit PC architectures, C++ exceptions only add unreachable code with destructor calls into functions and their effect on performance is below 1%, but such low values are difficult to measure. Handling rare errors with return…

Your "better comparison" finds that error codes are slower than exceptions? It's right there at the top in bold even if you don't want to read the whole thing: > TL;DR On modern 64-bit PC architectures, C++ exceptions only add unreachable code with destructor calls into functions and their effect on performance is below 1%, but such low values are difficult to measure. Handling rare errors with return values requires…

> Unless you're arguing that it's better to just always have a 5% performance tax & manual, error-prone error handling?

Exceptions today are untenable for a library author because you don't know which input data your callers will use, and therefore can't predict how often errors will be thrown.

Ideally we'd fix c++ with better manual propagation of errors and compiler warnings, like Rust or Zig.

Even if the global mutex is fixed, the single threaded perf numbers are terrible if you hit a bunch of unexpected errors. That seems unfixable.

I'd rather have 5% slower code, than 5% faster code with occasional 1000% slow downs (in the worst case).

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

#512

Post by kllrnohj » Mon, Feb 28, 2022, 10:24 PM UTC

randyrand wrote: post #511

kllrnohj wrote: post #502

Earlier quoted context omitted.

Your "better comparison" finds that error codes are slower than exceptions? It's right there at the top in bold even if you don't want to read the whole thing: > TL;DR On modern 64-bit PC architectures, C++ exceptions only add unreachable code with destructor calls into functions and their effect on performance is below 1%, but such low values are difficult to measure. Handling rare errors with return values requires…

> Unless you're arguing that it's better to just always have a 5% performance tax & manual, error-prone error handling? Exceptions today are untenable for a library author because you don't know which input data your callers will use, and therefore can't predict how often errors will be thrown. Ideally we'd fix c++ with better manual propagation of errors and compiler warnings, like Rust or Zig. Even if the global mu…

> I'd rather have 5% slower code, than 5% faster code with occasional 1000% slow downs (in the worst case).

Perhaps, but that's a strawman through & through. C++ exceptions don't have that performance cliff when thrown, per both the paper in the OP & in your link. They are fairly cheap to throw assuming a single-threaded application.

That is, the fib example with 10% failure rate has the same performance using exceptions & using Boost::LEAF.

Unless you're calling it "unfixable" because there isn't actually anything to fix in the first place...

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

#513

Post by [deleted] » Fri, Mar 04, 2022, 8:20 AM UTC

ncmncm wrote: post #398

kinjba11 wrote: post #386

Earlier quoted context omitted.

> my experience essentially does not involve catching exceptions Which is part of the problem. If you're not catching the exception, you don't need exceptions. You just need a way to log stuff, such as a trace, and exit the program. New languages such as Rust and Go encourage this explicitly - that is, use the ordained error path in the return value for expected errors, and only panic for catastrophic errors (or use…

When you are writing a library, you don't know what the program that calls you might have set up to handle failures, but you know exactly how to get to it: throw, and you are there, and it is now for the caller to decide what to do, thus not your problem. A library that exits has stolen control away from its rightful owner. Very few languages are as finely tuned to the needs of libraries and users of libraries as C++…

[deleted]

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

#514

Post by kinjba11 » Fri, Mar 04, 2022, 8:24 AM UTC

Too wrote: post #403

kinjba11 wrote: post #386

Earlier quoted context omitted.

> my experience essentially does not involve catching exceptions Which is part of the problem. If you're not catching the exception, you don't need exceptions. You just need a way to log stuff, such as a trace, and exit the program. New languages such as Rust and Go encourage this explicitly - that is, use the ordained error path in the return value for expected errors, and only panic for catastrophic errors (or use…

”If you're not catching the exception, you don't need” Exactly. But the upstream caller of your function might need it. And that’s the beauty of it. If I don’t know how to handle a particular error in one context, I can just leave it and let it propagate upwards. For example downloadFile()->parseHttpResponseStrean()->readSocket() If readSocket throws a timeoutError I don’t need every http library to explicitly deal w…

Instead of catching an error why not just return it. Then it's obvious to anyone reading that an error can happen there.

    auto fileOrError = downloadFile();
    if (fileOrError is error) {...}

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

#515

Post by kinjba11 » Fri, Mar 04, 2022, 8:32 AM UTC

ncmncm wrote: post #398

kinjba11 wrote: post #386

Earlier quoted context omitted.

> my experience essentially does not involve catching exceptions Which is part of the problem. If you're not catching the exception, you don't need exceptions. You just need a way to log stuff, such as a trace, and exit the program. New languages such as Rust and Go encourage this explicitly - that is, use the ordained error path in the return value for expected errors, and only panic for catastrophic errors (or use…

When you are writing a library, you don't know what the program that calls you might have set up to handle failures, but you know exactly how to get to it: throw, and you are there, and it is now for the caller to decide what to do, thus not your problem. A library that exits has stolen control away from its rightful owner. Very few languages are as finely tuned to the needs of libraries and users of libraries as C++…

In any case, these arguments have been hashed many times.

I always recommend reading Joe Duffy's post on errors for the curious.

http://joeduffyblog.com/2016/02/07/the-error-model/

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

#516

Post by Too » Sun, Mar 06, 2022, 7:10 AM UTC

kinjba11 wrote: post #514

Too wrote: post #403

Earlier quoted context omitted.

”If you're not catching the exception, you don't need” Exactly. But the upstream caller of your function might need it. And that’s the beauty of it. If I don’t know how to handle a particular error in one context, I can just leave it and let it propagate upwards. For example downloadFile()->parseHttpResponseStrean()->readSocket() If readSocket throws a timeoutError I don’t need every http library to explicitly deal w…

Instead of catching an error why not just return it. Then it's obvious to anyone reading that an error can happen there. auto fileOrError = downloadFile(); if (fileOrError is error) {...}

Because half of your program will look like this

    if err != nil {
        …
    }

Just take a look at any golang project, it has more error handling than business logic. If you are writing flight avionics sw this might be a good thing, but for my cat pic sharing MVP I’m happy to just print “unhandled internal error” when the DB stops responding due to unusual hug of death overload. There is nothing else that can be done to recover this error anyway.

On top of this it still isn’t bullet proof. There are infinite number of errors that can happen almost anywhere, especially when IO is involved; Disconnects, Time-outs, StackOverflow, ArrayOutOfBounds, DivideByZero, Overflow, NoSuchKeyInDictionary. And so on and so on.

Going back to go, Many low quality libraries still use panic, which gives you two ways to handle errors, one which is considered exotic so you don’t normally put recover() in place, then get bitten at worst moment.

Another example being Java where checked exceptions force beginners to handle errors, where most people don’t know what to do about it, so they just log.error() and return a dummy value, giving no way for upstream to detect such error and causing the program to blow up later instead. That said, checked exceptions is probably the best middle ground between verbosity and safety. It’s just greatly misunderstood.