Remember kids, always use try catch
this post was submitted on 21 Nov 2025
264 points (96.5% liked)
Technology
77001 readers
2086 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
I swear some of these commenters will jerk each other off about how "Rust is bad, actually" even if the root cause of an issue was someone intentionally crashing their app. Where do you even get this kind of attitude from? I've been around when Rust was the popular topic in any programming-related discussions and while there was plenty of evangelism and CS-101 experts making wild claims, nothing warrants this kind of irrational hatred. I thought you need to go to the phoronix forums to find people who have such loud opinions with very little actual programming experience, but apparently I was wrong.
Up until very recently, the cult of rust was going - very - strong on lemmy. Things have somewhat normalized by now, but for a long time, any programming related topic was full off, often ill informed, takes why “rust should have been used for this” and similar things. The Rust community has generally been extremely toxic as well, not helping its reputation. Now that we are a few years in and various major Rust projects have had numerous embarrassing bugs reality has sunk in, but as these things go, the backlash will last longer on the internet than the hype ever has.
The internet would be a much quieter place if people were forced to have a minimal amount of insight into the topic they're posting about. I guess what really annoys me is when popular blogs like this one deliberately frame something they don't like in a way that makes it look worse to people who don't know any better. There are very few people calling this shit out, be it on lemmy or the comments of the article itself. They even lied about FL1 being "bullet-proof" and "unaffected" by this bug, when it clearly wasn't, according to Cloudflare - the primary source of this shitstain of an article.
Just because you’re writing in a shiny new language that never misses an opportunity to crow about how memory safe it is, doesn’t mean that you can skip due diligence on input validation, checking every return value and writing exception handlers for even the most unlikely of situations.
Lol
But at least it wasn't a memory leak!!! 😭😭😭
Memory leaks are logic errors, Rust can't really prevent you from leaking memory.
It's really hard to do without Rc (or similar) or unsafe.
You can leak memory in perfectly safe Rust, because it is not a bug per se, an example is by using Box::leak
Preventing memory leaks was never in the intentions of Rust. What it tries to safeguard you from are Memory Safety bugs like the infamous and common double free.
And it still cleans up once the ownership model indicates it can be cleaned up. That does not ensure memory is never leaked, but it is equivalent to destructors running automatically when using unique ptr or shared ptr without cycles in C++, which avoids at least a portion of possible memory leaks.
Some memory leaks are logic errors, and this is honestly the irony of modern dynamic languages. I have actually gotten into the argument in interviews before - it is arguably safer (and better) to work from maximal static memory allocations with memory safe data objects than it is to implement dynamic memory algorithms just because they are fun coding problems.
I swear, every time I start to think that I go overboard with this sort of shit in my scripts for work, I either find another ridiculous edge case or a story like this comes out.
It's crazy that cloudflare of all people even had unwrap enabled. Whenever I use unwrap in some tiny little not important thing I always treat it as a temporary thing that I need to come back and fix before the software is actually ready for anyone to seriously use
There's nothing more permanent than a "temporary" fix.
Yeah but man, they should have had a CI against this. And reviews! I have refused to merge PRs from friends on hobby projects for less than that
PM: Listen it’s almost December, the whole team decided to cash in PTO next week for thanksgiving, it’s 4pm on a Friday, and the quarter is about to end. We have to move onto next quarter’s OKRs. Is this good enough to ship?
A very tired dev: …lgtm
Other than permanent fixes
As always, there's a clippy rule for that.
It's called clip because it stays. /s
I feel like I've seen an insane number of error messages in various apps and websites around the unwrap method.
But this is on a result type, right? I'd figure the point would be that you would match on it and that the unwrap itself, which if my assumptions are correct, is more like get value or throw, should either not exist or take a default value. You shouldn't be able to directly get the value of a monad.
There is a function that does what you are asking for.
.unarap_or()
It either unwraps the value or uses a provided default. Personally, i think unwrap() should be renamed unwrap_or_panic() to follow existing conventions and prevent confusion for non-rust programmers.
I don't think non-rust programmers are programming in Rust, LLMs on the other hand..
If you think only llms can do these kind of beginner mistakes you are mistaken. That's the whole point of the argument.
"unwrap should not exist" is true as long as you don't want to ever use the language. If you actually want to use it, you need it. At least while developing.
Some values cannot have a default value. And some cases it's preferable to panic even if it has a default value.
unwrap is not the problem. Cloudflare's usage is.
I feel like I’ve seen an insane number of error messages in various apps and websites around the unwrap method.
I suspect this is related to LLM usage somehow. We'll probably see a lot more of this type of problem (sudden flareups of a particular bad code implementation)
I actually disagree, because I've both seen it everywhere and I also work mainly in dotnet, and when I've talked to people about option and result types, the first inclination is to have a .Value, but that defeats the purpose. I've done quite a few code reviews where I was essentially saying "you know this will throw, right? Use .Match or .Map instead".
I think the imperative programming backgrounds encourage this line of thinking, since one of the first questions I've gotten is "how do I get the value out of an Option? I'm 100% sure it's there." And often, surprise, it wasn't.
load more comments
(2 replies)
There are good reasons to have unwrap or at least expect. There is no reason to use it in the case that Cloudflare used it in.
Rust has exceptions? Is that new?
No, the article is just not very precise with its words. It was causing the program to panic.
They're probably trying to write it in a way that non-Rust-developers can understand.
Replace uncaught exception for unhanded error.
unhanded error
underhanded error /s
No, it's a panic, so it's more similar to a segfault, but with some amount of unwinding. It can be "caught" but only at a thread boundary.
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.
I see you ignored my entire comment.
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.
load more comments
(1 replies)
It not exactly unwrap fault even if it would wrote in other way it still not work cause of wrong SQL request which spamming with results longer than expected to rust here was protecting from memory leak actually
It is unwrap's fault. If they did it properly, they would've had to explicitly deal with the problem, which could clarify exactly what the problem is. In this case, I'd probably use expect() to add context. Also, when doing anything with strict size requirements, I would also explicitly check the size to make sure it'll fit, again, for better error reporting.
Proper error reporting could've made this a 5-min investigation.
Also, the problem in the first place should've been caught with unit tests and a test deploy. Our process here is:
- Any significant change to queries is tested with a copy of production data
- All changes are tested in a staging environment similar to production
- All hotfixes are tested with a copy of production data
And we're not a massive software shop, we have a few dozen devs in a company of thousands of people. If I worked at Cloudflare, I'd have more rigorous standards given the global impact of a bug (we have a few hundred users, not billions like Cloudflare).
view more: next ›