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

[jcelerier]

> I am the the original author, and trust me, I am describing a real world problem.

for a more-or-less niche part of "real world". The overwhelming majority of desktop GUI apps rely on some C++ system - Qt, gtkmm, Wx, Blink, Gecko, FLTK, etc etc... and it is not an issue for those, for what exceptions are commonly used for (a write failing because the user disconnected the USB drive while it was copying, a system resource limit exhausted.. things like that). As much as massive parallel data processing tasks matter, I'd really prefer my language to not side-step writing end-user apps for something that happens at $bigcompany or $bigresearchlab.

here's the list of binaries that link against libstdc++.so.6 in my /usr/bin: https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 - don't forget those please :)

[mcguire → jcelerier]

Are you arguing that C++ is unsuitable for massive parallel data processing tasks?

[jandrese → mcguire]

I think he's arguing that C++ exceptions are unsuitable for parallel data processing, at least in cases where exceptions are regularly thrown.

[jcelerier → jandrese]

If exceptions are regularly thrown the software has a bad design and must be fixed. Non-exceptional stuff must of course not be handled through exceptions - no exception should ever be thrown if the software operates as it is expected to.

[ncmncm → jandrese]

There is the red flag: "regularly thrown". "Regularly" is opposite to "exceptionally".

[gpderetta → jandrese]

Well of course, they are slow so they are unsuitable. The issue is whether they need to be slow.

[garbagecoder → mcguire]

No, he's arguing that he'd prefer it not be if that means breaking support for end user apps which is what the OP is arguing for.

[jcelerier → mcguire]

No, of course not. But let's not change the language in ways that benefits those use cases at the detriment of more common use cases.

Of course, if there are ways to keep more or less the same semantics, while increasing performance, by all means it should be done !

[PaulDavisThe1st → mcguire]

for ones that throw an exception for 1% of a unit computation, perhaps yes.

But as has been noted, that's a lot of failures and exceptions may not be the appropriate mechanism to deal with this type of failure.

[ncmncm → PaulDavisThe1st]

Indeed, arithmetic errors are what NaN was invented for. It still works, and is fast.