On November 18 of 2025 a large part of the Internet suddenly cried out and went silent, as Cloudflare’s infrastructure suffered the software equivalent of a cardiac arrest. After much panicke…
An unhanded error will always result on a panic (or a halt I guess). You cannot continue the execution of the program without handling an error (remember, just ignoring it is a form of handling). You either handle the error and continue execution, or you don’t and stop execution.
A panic is very far from a segfault. In apparent result, it is the same. However, a panic is a controlled stopping of the program’s execution. A segfault is a forced execution stop by the OS.
But the OS can only know that it has to segfault if a program accesses memory outside its control.
If the program accesses memory that it’s under it’s control, but is outside bounds, then the program will not stop the execution, and this is way worse.
EDIT:
As you said, it’s also an important difference that a panic will just stop the thread, not the entire process.
Yes, it’s not the same since you get a stacktrace (if enabled) and a message, but it’s the closest thing you get in safe rust (outside compiler bugs). I compare it to a segfault because it’s almost as unhandleble.
Basically, you don’t want a panic to crash your program in most cases. If you do, make it explicit (i.e. with expect()). unwrap() tells me the value is absolutely there or the dev is lazy, and I always assume the latter unless there’s an explanation (or it’s obvious from context) otherwise.
I don’t know what is more explicit about expect. Unwrap is as explicit as it gets without directly calling panic!, it’s only 1 abstraction level away. It’s literally the same as expect, but without a string argument. It’s probably top 10 functions most commonly used in rust, every rust programmer knows what unwrap does.
Any code reviewer should be able to see that unwrap and flag it as a potential issue. It’s not a weird function with an obscure panic side effect. It can only do 2 things: panic or not panic, it can be implemented in a single line. 3 lines if the panic! Is on a different line to the if statement.
An unhanded error will always result on a panic (or a halt I guess). You cannot continue the execution of the program without handling an error (remember, just ignoring it is a form of handling). You either handle the error and continue execution, or you don’t and stop execution.
A panic is very far from a segfault. In apparent result, it is the same. However, a panic is a controlled stopping of the program’s execution. A segfault is a forced execution stop by the OS.
But the OS can only know that it has to segfault if a program accesses memory outside its control.
If the program accesses memory that it’s under it’s control, but is outside bounds, then the program will not stop the execution, and this is way worse.
EDIT: As you said, it’s also an important difference that a panic will just stop the thread, not the entire process.
Yes, it’s not the same since you get a stacktrace (if enabled) and a message, but it’s the closest thing you get in safe rust (outside compiler bugs). I compare it to a segfault because it’s almost as unhandleble.
Basically, you don’t want a panic to crash your program in most cases. If you do, make it explicit (i.e. with
expect()).unwrap()tells me the value is absolutely there or the dev is lazy, and I always assume the latter unless there’s an explanation (or it’s obvious from context) otherwise.I see you ignored my entire comment.
I don’t know what is more explicit about expect. Unwrap is as explicit as it gets without directly calling panic!, it’s only 1 abstraction level away. It’s literally the same as expect, but without a string argument. It’s probably top 10 functions most commonly used in rust, every rust programmer knows what unwrap does.
Any code reviewer should be able to see that unwrap and flag it as a potential issue. It’s not a weird function with an obscure panic side effect. It can only do 2 things: panic or not panic, it can be implemented in a single line. 3 lines if the panic! Is on a different line to the if statement.