News for hackers. Stuff that matters.

A comment on The Year of C++ Successor Languages. Parent comment

Re:The Year of C++ Successor Languages by zozbot234 on Monday January 02, 2023 @05:50AM (#34216531)
Go does have exceptions, via panic/recover. You could argue that Rust lacks true exceptions because a Rust panic can be configured to be fatal at the whole-program level. (Which is actually great for deep-embedded scenarios where even C++ use is with no-exceptions support.)
[ Parent | on HN ]
Re:The Year of C++ Successor Languages by usrnm on Monday January 02, 2023 @06:35AM (#34216848)
Yeah, it's funny how go does have exceptions, but no notion of exception safety. Manual mutex locks/unlocks are everywhere, and don't even start me on defer, which is just terrible
[ Parent | on HN ]
Re:The Year of C++ Successor Languages by mike_hock on Tuesday January 03, 2023 @03:53AM (#34229362)
That's how you get a "simple" language.
[ Parent | on HN ]
Re:The Year of C++ Successor Languages by IshKebab on Monday January 02, 2023 @05:32PM (#34224631)
Those are not exceptions by most reasonable definitions. Exceptions are a general purpose error handling method. Try, catch and all that. They are almost always objects with multiple types.

Go and Rust's panic is for unrecoverable errors. They both have the ability to catch panics because sometimes you really need to do that (e.g. when interacting with FFI or sometimes multithreaded code).

They are not exceptions though. I've seen this myth repeated a few times lately (always about Go and not Rust for some reason) and I wish it would die.

You wouldn't say C "has exceptions" would you?

[ Parent | on HN ]
Re:The Year of C++ Successor Languages by pipologist on Monday January 02, 2023 @06:09PM (#34225015)
That’s being stuck on usage patterns. Any automatic stack unwinding mechanism is the same. Whether C++ exceptions and Rust’s panics.
[ Parent | on HN ]
Re:The Year of C++ Successor Languages by dureuill on Tuesday January 03, 2023 @03:05AM (#34229047)
> You wouldn't say C "has exceptions" would you?

Maybe that's just me, but I wish more people would say that C "has exceptions", if only because longjmp/setjmp[0] interacts with exception systems of other languages, sometimes badly.

That being said, I think an important difference is that in C setjmp/longjmp do not "unwind" objects, due to the lack of destructors.

However panics at least in Rust are just exceptions by another name. The difference solely comes from culture. Even the fact that unwind can be turned to abort is not significant, considering that pretty much all production implementations of C++ have fno-exceptions

[0]: https://learn.microsoft.com/en-us/cpp/cpp/using-setjmp-longj...

[ Parent | on HN ]
Re:The Year of C++ Successor Languages by IshKebab on Tuesday January 03, 2023 @04:02AM (#34229418)
> That being said, I think an important difference is that in C setjmp/longjmp do not "unwind" objects, due to the lack of destructors.

I don't think that is a requirement of exceptions. It's just a sensible thing that most implementations do.

> The difference solely comes from culture.

Maybe, but that is a huge difference! You can implement anything in any Turing complete language but you wouldn't say that they all "have" every feature...

To quote https://doc.rust-lang.org/std/panic/fn.catch_unwind.html :

> It is *not* recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below.

[ Parent | on HN ]