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

401–410 of 516 posts

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

#401

Post by ncmncm »

jerf wrote: post #206
zozbot234 wrote: post #130

Earlier quoted context omitted.

> it still seems like it has settled into a lower-frequency churn rate lately for "best practices" than C++. Rust is still adding a ton of new language features, especially around async, compile time code evaluation and the type system (const generics, GAT/HKT, existential types etc.). We'll very likely see further developments in more areas next, e.g. to match C++ developments in parallel and heterogenous compute (G…

A lot of that is not what I mean by "churn". What I mean by "churn" is changes in best practice . Python has been adding a lot of features, but with the possible exception of static typing support, most of them haven't made many changes to what constitutes best practices . They might make "nicer ways to write that code" but the old styles haven't been deemed wrong . async is also not exactly what I mean; this allows…

C++ gets new features that provide a better way to solve common coding problems. This is not accidental, and not a problem: the new features were added because they offer that better way.

Failing to use the new feature is just failing to write code the best way that is available right now. In 2013 you had no choice but to do it the old way; but you don't have to anymore, because the language and std library have caught up with you.

Being responsive to the needs of its community of programmers is job one for a language committee. If new, better ways don't arise, your language has stagnated.

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

#402

Post by ncmncm »

ModernMech wrote: post #380
MauranKilom wrote: post #198

Earlier quoted context omitted.

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.

A language that has stopped responding to the evolving needs of its user community is a dead language. C++ is not a dead language.

Your complaint is that it is not dead.

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

#403

Post by Too »

kinjba11 wrote: post #386
Traster wrote: post #328

Earlier quoted context omitted.

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…

> 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 with it. What can they even do about it, apart from retrying? The application level code calling the downloadFile function is still free to catch the error and gracefully show an error to the user or use a default file from disk if they please.

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

#404

Post by ncmncm »

JAlexoid wrote: post #330
jcelerier wrote: post #292

Earlier quoted context omitted.

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.

No contradiction.

It is not the job of a general-purpose language to insert its own opinions. That is the system designer's job. Fighting with the language's opinions is a recipe for failure.

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

#405

Post by ncmncm »

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…

Any exception thrown in response to a bug is a fundamental design failure.

At the point where it is evident the program has a bug, there is nothing known, anymore, about the state of the program. It means that data structures defining the state are inconsistent to a wholly unknown degree, and any further computation depending on or,worse, altering that state can do no better than compound the failure.

I always delete code I find that tries to recover from a bug. It is impossible to recover from a bug; the best that can be done is to bail out as fast as possible.

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

#406

Post by ncmncm »

zmmmmm wrote: post #314
mcguire wrote: post #177

Earlier quoted context omitted.

" 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 a system's API This is a really interesting and nuanced point here. The article linked above [1] talks a bit about it. The problem is, they both are and aren't part of the API in the strict sense. In the sense that they specify a contractual behaviour they are part of the API of a function. But in the sense that they are something the caller should / needs to specifically care about, they sit in…

It is still far too early to say.

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

#407

Post by fulafel »

worik wrote: post #44

Begs the question: Why C++? Legacy projects (I am not being pejorative, they are important) which must be maintained aside, should not C++ be deprecated? We have many new languages, we always had C. What does C++ give us in 2022 that makes up for the enormous cognitive load of understanding and keeping up with it.

There are still some environments where security/safety does not matter much and modern alternatives don't target. Like firmware for a RC project, or a non networked or sandboxed platform game where tooling for other languages is missing (like consoles). If you already know C++ and risks down the road very well.

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

#408

Post by ncmncm »

PaulDavisThe1st wrote: post #185
mcguire wrote: post #171

Earlier quoted context omitted.

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

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.

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

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

#409

Post by atq2119 »

gumby wrote: post #232
cryptonector wrote: post #220

Earlier quoted context omitted.

I agree. I'm not sure breaking the ABI to fix the unwinder serialization issue should be a show-stopper, considering that there still isn't a C++ ABI.

Th problem is that the corpus of deployed libraries is a de facto ABI. Even with dylib versioning, catching the case of API version is hard. I think it could be done by changing the mangling algorithm (basically: compile fails if new-ABI versions are not available) but I haven't thought enough about it to remove the words "I think" from the beginning of the sentence.

Since this is about immutable "side car" data structures used during unwinding: could this be achieved using a soft ABI transition as opposed to a hard, flag day ABI break?

Basically, going forward the compiler would emit two versions of the unwinding tables by default: the legacy one and the one that allows fixing the thread contention issue. The unwinder is changed to use the efficient version by default with the ability to fall back to locking if it encounters a shared object that only has the old version.

Space conscious users could choose to emit only one version by using a compiler flag, and after a decade or so the compiler is switched to only emit the new version by default (but the unwinder could retain the capability to understand the old format for a few decades longer).

It seems like most of the table contents should even be shareable between versions? The locking seems to be only there to guard against shared object loading/unloading which should only affect the topmost level of the data structure.

Admittedly I have no idea how those tables are actually defined today.

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

#410

Post by atq2119 »

kllrnohj wrote: post #354
fivea wrote: post #251

Earlier quoted context omitted.

> If you write a jpeg-processing service, it’s intuitive to raise an exception on a malformed jpeg (..) Not really. Having to parse a malformed doc is not an exceptional situation: it's a basic use case, and one which is very close to the happy path.

And it's one for which exceptions are a perfect fit. Even if at the entry point of your "parseJpeg()" function you instead return a variant , internally propagating that error via exceptions is the "correct" design. Otherwise you're littering the code with branches, which makes the expected common path slower. Which the paper covers, that's the std::expected section: http://www.open-std.org/jtc1/sc22/wg21/docs/papers…

If your service is public facing and therefore subject to DoS attacks, you should design around the error path being fast.

Which really should be possible with exceptions. It's a shame that it isn't.

Post reply on HN