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…
No, I responded to the relevant part. I was using segfault as a metaphor, not arguing that it’s actually the same mechanism underneath. If you’re getting panics in production code, I consider that just as much of an emergency to fix as a segfault, and Rust helpfully gives you stack trace info with it. It’s not the same idea as an exception, which could signify an unrecoverable error or an expected issue that can be recovered from.
I don’t know what is more explicit about expect
It forces you to write a message, so most temporary uses will be unwrap(). I use unwrap() all the time when prototyping for the happy path, and then do proper error handling later. This is especially true in larger projects where I can’t just throw in anyhow or something and actually need to map error types and whatnot. I don’t use expect() much (current hobby project has 4 uses, 3 for startup issues and 1 for hopefully impossible condition) but I think it makes sense when there’s no way to continue.
But yes, unwrap() is perhaps the first thing I look for as a reviewer, which is why it’s so surprising that this is the issue. At the very least, it should have been something like expect("exceeds max file size"). I personally prefer explicit panics in production code, but expect is close enough that it’s personal preference.
No, I responded to the relevant part. I was using
segfaultas a metaphor, not arguing that it’s actually the same mechanism underneath. If you’re getting panics in production code, I consider that just as much of an emergency to fix as a segfault, and Rust helpfully gives you stack trace info with it. It’s not the same idea as an exception, which could signify an unrecoverable error or an expected issue that can be recovered from.It forces you to write a message, so most temporary uses will be
unwrap(). I useunwrap()all the time when prototyping for the happy path, and then do proper error handling later. This is especially true in larger projects where I can’t just throw inanyhowor something and actually need to map error types and whatnot. I don’t useexpect()much (current hobby project has 4 uses, 3 for startup issues and 1 for hopefully impossible condition) but I think it makes sense when there’s no way to continue.But yes,
unwrap()is perhaps the first thing I look for as a reviewer, which is why it’s so surprising that this is the issue. At the very least, it should have been something likeexpect("exceeds max file size"). I personally prefer explicit panics in production code, but expect is close enough that it’s personal preference.