And we slowly circle back to what Rust should have done all along: exceptions with Java/Python-style causal chaining.

I wonder how loudly "the community" would scream at me if I published something that just used panics for all error reporting.

▲

dwattttt 4 days ago | parent | next [-]

I've been following Raymond Chen's recent series on writing a tracking C++ pointer class with interest.

Most of the articles start with "to fix the mistake we showed at the end of the last article", and end with "but now we've broken something else".

Needing to keep track of where exceptions can occur, so that you don't leave an operation half committed, sounds especially nasty: https://devblogs.microsoft.com/oldnewthing/20250827-00/?p=11...

▲

nromiun 4 days ago | parent | next [-]

A lot of things are broken in C++. Like coroutines, exceptions, parallel execution (std::execution) etc. That does not mean the core ideas are bad and we should stop using them in every language.

	▲	tialaramex 4 days ago \| parent [-]
		I suspect too much is broken (well, I'd say more clearly "crap") in C++ to be sure whether any particular core ideas hold up based on that whole language. I'm particularly mindful of C++ 26 Erroneous Behaviour for initialization. This idea was introduced for the forthcoming C++ 26 language version, it says that although just making a variable `int k;` and then later taking its value is an error, it's no longer Undefined Behaviour, the compiler shall arrange that it has some specific value. This is a meaningful improvement over the C++ status quo. But, that doesn't mean the core idea is actually good. It's bad to do this in your language, they didn't have any better choice for C++ for historical reasons so this was the least bad option.

▲

quotemstr 4 days ago | parent | prev | next [-]

You still have to be exception safe in Rust, you know. What do you think a panic is? Rust really has the worst of both worlds.

	▲	dwattttt 4 days ago \| parent [-]
		Agreed, and I wish there were more emphasis on ensuring panic free sections of Rust code.

▲

lenkite 4 days ago | parent | prev [-]

Yeah, well C++ built a faulty bridge and screwed the pooch for future language designers who now all say "bridges are harmful".

▲

ninkendo 4 days ago | parent | prev [-]

Except the java/python style with unchecked exceptions means an exception can happen at any time, there's no way to know in advance. This is what Rust is trying to avoid with the errors-as-values approach.

It has its drawbacks, yes, but I'd never go back to the wild-west YOLO approach of unchecked exceptions, personally.

▲

zaphar 4 days ago | parent [-]

To be fair, Rust could have done CheckedExceptions like Java has but no one uses. The problematic version is the RuntimeException. I think the real problem was that when Rust conceived of Result they didn't constrain the problem to just error handling and made it a little bit too much "anything goes". Which means that trying to shoehorn backtraces in after the fact with `?` and `try_into` is now hard. There could have been a world where `Result::Err` was actually a wrapper type that specified an optional source error for backtracing and the generic type was embedded in that instead. It would have been less flexible but it would have made proper backtraces more tractable.

▲

ninkendo 4 days ago | parent [-]

Is there a language that has proper exclusively checked exceptions? That is, not just syntax sugar around checking an error value (à la Swift), but actual “the processor signals an exception” semantics, but all exceptions are still enforced to be handled-or-passed by the compiler?

Honest question, because I can’t think of any. I can see it being advantageous to have checked-only exceptions but there has to be a good reason why it’s so rare-to-never that we see it.

I’m not sure how else you’d get the holy grail, which I’d define as:

1. The compiler enforces that you either handle an exception or pass it to the caller

2. Accurate and fine-grained stack traces on an error (built-in, not opt-in from some error library du jour)

3. (ideally) no runtime cost for non-exception paths (no branches checking for errors, exceptions are real hardware traps)

C++ has 2 and 3, Java has only 2 (because RuntimeException exists), Rust has only 1. I’d love a language with 1 and 2, but all 3 would be great.

	▲	zaphar 2 days ago \| parent \| next [-]
		I can't think of any either. A sibling commenter suggests maybe Eiffel but I haven't really tried or looked at that language so I don't know if it's true. I think having all 3 would be great but if I can only choose one of them I personally prefer #1.
	▲	malkia 4 days ago \| parent \| prev [-]
		I've heard Eiffel has them better, but haven't used it. And then Koka too, but I have zero experience... Someon might shine light here about this...