Comment by stmw
11 hours ago
I'm simultaneously amused and concerned by the recurring proposals for Rust to add
1. exceptions 2. garbage collection
Sometimes in slightly modified forms or names, and often with very well-articulated, technically competent justifications (as is the case here).
Just say no!
But the argument is not about adding exceptions to the language.
It's about borrowing a technique from languages that do have exceptions (and Rust's own panic unwinding) to implement Rust's existing error handling without making any changes to the language.
The post is light on how this would actually work, though. I think that re-using the name "stack unwinding" is a little misleading. The stack would only unwind if the error was bubbled up, which would only happen if the programmer coded it to. Indeed, the error could just get dropped anywhere up the stack, stopping it from unwinding further.
I think this would be tricky to implement, since the compiler would have to figure out which code actually is on the error path, and any given function could have multiple error paths (as many as one per each incoming error return, if they're all handled differently). It'd also make Result<T,E> even more special than it already is.
All that having been said, if you squint a bit, the end result does vaguely resemble Java's checked exceptions.
And that was really my (unpopular) opinion above - that exceptions and garbage collectors are two examples of runtime/compiler/language features that after some iteration around the corner cases tend to end up in roughly the same place Java did 20+ years ago - as you say, "if you squint a bit".
It is interesting to think why it is so for exceptions specifically. The discussion here offers some of the possible reasons, I think, including violent disagreement of what we all even mean by exceptions vs stack unwinding vs error propagation.
This doesn't have anything to do with exceptions, and the context appears to be Zig, not Rust.
The article is about how we represent errors not their control flow (i.e., exceptions).
Fair point re: Zig vs Rust, but my larger point was about exceptions by any other name, in the linked article:
"Instead, when returning an error, rather than jumping to the return address, we look it up in the side table to find a corresponding error recovery address, and jump to that. Stack unwinding!
The bold claim is that unwinding is the optimal thing to do! .."
If by "exceptions" you're talking about stack unwinding (as opposed to the language-level control flow constructs like throw/catch) then Rust has always had that with panics and panic=unwind.
1 reply →
For clarification, this is not just a Rust, or a Zig thing. [removed incorrect info re: Linux]
To be clear, that has nothing to do with exceptions, garbage collection, or error ABIs. But I guess you're saying it's a case of tacking on language features to languages that don't have them, since the main desired MS extension is one that sort of resembles class inheritance.
You're completely right, I was wrong - thank you for the correction.
Adding ref to the SEH part of Microsoft C extensions https://learn.microsoft.com/en-us/cpp/cpp/structured-excepti...
Rust already has exceptions (when panic=unwind)
But it's not really encouraged as it is in C++ or Java. Quoting Rustonomicon: "There is an API called catch_unwind that enables catching a panic without spawning a thread. Still, we would encourage you to only do this sparingly. In particular, Rust's current unwinding implementation is heavily optimized for the "doesn't unwind" case. If a program doesn't unwind, there should be no runtime cost for the program being ready to unwind. As a consequence, actually unwinding will be more expensive than in e.g. Java. Don't build your programs to unwind under normal circumstances. Ideally, you should only panic for programming errors or extreme problems."