The worst part about rust not having exceptions is that it actually does have exceptions, you just shouldn't use them. All the downsides and none of the benefits:
No, Rust does not have exceptions. Rust has unwinding, if you choose to compile your program with support for it, which you are free not to, and is trivially achieved by a single flag.
It's hard for me to think of a definition of "exception" which doesn't include Rust's panics:
use std::panic::catch_unwind;
fn throws_exception(){
panic!("hello");
}
fn main(){
match catch_unwind(|| {
throws_exception();
println!("Never reached");
}) {
Ok(_) => (),
Err(e) => println!(
"threw an exception: {:?}",
e.downcast_ref::<&'static str>().unwrap())
}
}
I can disable exceptions in rustc, but I can't disable the influence they have on language and library design (as detailed in the link I posted). Exceptions are the main reason you can't temporarily move something out from behind an exclusive reference, or return an error code from a Drop impl. Heck, Rust wouldn't even need destructors if it weren't for exceptions: the compiler could just tell you when you forgot to free something.
No, panics are not exceptions. Exceptions are a mechanism for resumable error-handling. Rust's `catch_unwind` function is a last-ditch mechanism for failure isolation (motivated by preventing UB via unwinding across FFI boundaries), not a general-purpose error recovery mechanism. I have seen many Rust programs in my day, and not a single one has ever used `catch_unwind` in the way that (say) Java or Python programmers use try/catch for error handling, so this is as true in practice as it is in theory.
> I can disable exceptions in rustc, but I can't disable the influence they have on language and library design
It's the other way around. The fact that unwinding can be (and regularly is) trivially disabled is the ultimate motivator of why panics fundamentally cannot be used for error handling, and this is what influences language and library design (ultimately demanding `Result`-based error handling).
> Exceptions are the main reason you can't temporarily move something out from behind an exclusive reference, or return an error code from a Drop impl
No, this is absolutely untrue, and I'm not sure why you think this.
> Heck, Rust wouldn't even need destructors if it weren't for exceptions: the compiler could just tell you when you forgot to free something.
No, this is also untrue, and you appear to misunderstand the purpose of destructors. Feel free to provide code if you would like to try to make a more precise argument against unwinding.
> Exceptions are a mechanism for resumable error-handling. Rust's `catch_unwind` function is a last-ditch mechanism for failure isolation
Tomayto Tomahto.
> I have seen many Rust programs in my day, and not a single one has ever used `catch_unwind`
Yeah, cause it sucks. Hence my original point: all downsides and no benefits. Also how people use Rust's exceptions has no bearing on whether or not they are exceptions.
> The fact that unwinding can be (and regularly is) trivially disabled is the ultimate motivator of why panics fundamentally cannot be used for error handling
Unwinding can be disabled in C++, too. They still call them exceptions over there.
> you appear to misunderstand the purpose of destructors.
In a language with exceptions, destructors (or something similar like try-finally) are required to guarantee resource cleanup. In a language without exceptions, it is enough to simply write the cleanup code at scope exit points. Rust's static analysis is strong enough to ensure you do this correctly in the hypothetical world where the language does not have exceptions.
If your insinuation here is that I don't understand why you might still want destructors in the absence of exceptions, then you've missed my point.
> Feel free to provide code if you would like to try to make a more precise argument against unwinding.
I already linked the precise argument against unwinding. It's written by Niko Matsakis, one of the core Rust language designers. It explains both the "temporary move from behind an exclusive reference" point and the "return a value from a drop impl" point (which the article calls "must move").
https://smallcultfollowing.com/babysteps/blog/2024/05/02/unw...