[flamedoge]

what.. noexcept throws exception..? what kind of infinite wisdom led to this

[chipdart]

> what.. noexcept throws exception..? what kind of infinite wisdom led to this

Not wisdom at all, just a very basic and predictable failsafe.

If a function that is declared to not throw any exception happens to throw one, the runtime handles that scenario as an eggregious violation of its contract. Consequently, as it does with any malformed code, it terminates the application.

[api]

There’s a reason both Go and Rust eschew exceptions. They’re something that superficially seemed like a great idea but that in practice complicate things by creating two exit paths for every function. They also don’t play nice with any form of async or dynamic programming.

C++ should never have had them, but we have sane clean C++ now. It’s called Rust.

[sobellian]

IMO the pendulum swung too far with Rust. The experience is better than C++, but the template generics system is not very powerful. They ostensibly made up for this with macros, but (a) they're annoying to write and (b) they're really annoying to read. For these reasons Rust is much safer than C++ but has difficulty providing fluent interfaces like Eigen. There are libraries that try, but AFAICT none match Eigen's ability to eliminate unnecessary allocation for subexpressions and equivalently performing Rust code looks much more imperative.

[forrestthewoods]

Rust panics are basically exceptions, aren’t they? Typically they aren’t caught without terminating. But you totally can. And if you’re writing a service that runs in the background you’ll probably have to.

[astral303]

If you find that exception-free code that is necessarily littered with exit value checks at every call, which discourages refactoring and adds massive noise, then you can call the decisions to eschew exceptions as “sane” and “clean”, but I find the resulting code to be neither. Or practically speaking, exit codes will often not be checked at all, or an error check will be omitted by mistake, thereby interrupting the entire intended error handling chain. Somehow that qualifies as a better outcome or more sane? Perhaps it is for a code base that is not changing (write-once) or is not expected to change (i.e. throwaway code written in “true microservice” style).

[b112]

Come back and explain to me how wonderfully perfect rust is, after it is as old as C variants. Let's say 2040 at the earliest, maybe 2050.

Legacy will affect rust too. It's not better, just younger.

I tend to think of coding languages as laws passed by parliaments. A lot of legacy laws, and regulations hang around pver time.

[pavlov]

Noexcept terminates if an exception is thrown within. That's a very C++ way to ensure that the exception can't propagate.