causing the program to crash if it actually was an error, restoring the more unsafe behavior of other languages.
Wellllll it’s more of an abrupt exit rather than a crash, which is still better than eg. silently accessing beyond the end of an array, or ending up with a pointer to nowhere when you thought you had a sane memory reference.
“An abrupt exit”, more commonly known as a “crash”.
If you’re going to argue that an exit through panic!() is not a crash, I will argue that your definition of a crash is just an abrupt exit initiated by the OS. In other words, there’s no meaningful distinction as the result is the same.
I don’t think that’s a valid comparison. The behavior does differ when it comes to cleanly releasing resources. Rust’s panic performs the drop actions for the current values on the stack, a SIGILL or SIGSEGV crash doesn’t.
#[derive(Debug)]
struct MyStruct {}
impl Drop for MyStruct {
fn drop(&mut self) {
println!("{:?}", "imagine cleanup here"); // this is called
}
}
fn main() {
let a = MyStruct {};
panic!("panic!");
println!("{a:?}");
}
That’s fair, although technically you could catch SIGSEGV and release resources that way too.
Also, given that resources will be reclaimed by the OS regardless of which kind of crash we’re talking about, the effective difference is usually (but not always) negligible.
Either way, no user would consider a panic!() to be not a crash because destructors ran. And most developers don’t either.
I was talking more about unwrap causing a panic rather than calling the actual panic macro directly. Rust forces the programmer to deal with bad or ambiguous results, and what that is exactly is entirely decided by the function you are calling. If a function decides to return None when (system timer mod 2 == 0), then you’d better check for None in your code. Edit: otherwise your code is ending now with a panic, as opposed to your code merrily trotting down the path of undefined behaviour and a segfault or similar later on.
Once you get to a point where we are doing the actual panic, well, that is starting to just be semantics.
Wellllll it’s more of an abrupt exit rather than a crash, which is still better than eg. silently accessing beyond the end of an array, or ending up with a pointer to nowhere when you thought you had a sane memory reference.
“An abrupt exit”, more commonly known as a “crash”.
If you’re going to argue that an exit through
panic!()is not a crash, I will argue that your definition of a crash is just an abrupt exit initiated by the OS. In other words, there’s no meaningful distinction as the result is the same.I don’t think that’s a valid comparison. The behavior does differ when it comes to cleanly releasing resources. Rust’s panic performs the drop actions for the current values on the stack, a SIGILL or SIGSEGV crash doesn’t.
Try it yourself
That’s fair, although technically you could catch SIGSEGV and release resources that way too.
Also, given that resources will be reclaimed by the OS regardless of which kind of crash we’re talking about, the effective difference is usually (but not always) negligible.
Either way, no user would consider a
panic!()to be not a crash because destructors ran. And most developers don’t either.I was talking more about unwrap causing a panic rather than calling the actual panic macro directly. Rust forces the programmer to deal with bad or ambiguous results, and what that is exactly is entirely decided by the function you are calling. If a function decides to return None when (system timer mod 2 == 0), then you’d better check for None in your code. Edit: otherwise your code is ending now with a panic, as opposed to your code merrily trotting down the path of undefined behaviour and a segfault or similar later on.
Once you get to a point where we are doing the actual panic, well, that is starting to just be semantics.