4 ms·
Rust programmers misuse unwrap and the like all the time, to the point that I’ve seen some projects explicitly state that they don’t do that, since nobody wants
by blub 4y ago
Rust programmers misuse unwrap and the like all the time, to the point that I’ve seen some projects explicitly state that they don’t do that, since nobody wants their library to crash their program because someone was too lazy to propagate errors.
Which brings me to the point: propagating errors is tedious enough that people are looking for shortcuts, which then cause other problems.
- spoiler 4y agoSomehow I must've been lucky enough to avoid this unwrap abuse in crates I use. I think you maybe meant converting between errors in Rust can be tedious sometimes, but propagation is pretty easy. The conversation is something that generally need's to happen rarely (like a few times per project?), but `thiserror` and `from` make this pretty ergonomic.
- burntsushi 4y agoFor other folks following along and possibly getting mislead by this (partial) nonsense, I'd encourage you to read a blog post I wrote about the topic of unwrap. I think it should clear up most things: https://blog.burntsushi.net/unwrap/ https://blog.burntsushi.net/unwrap/ At a meta level, one of the reasons why there is so much focus on 'unwrap()' in particular is because it is often the precise point at which in your code where a runtime invariant is broken and thus leads to a panic. Nearly all code has runtime invariants in one form or another. The question is what happens when they're broken. In languages that are memory unsafe by default, the answer is often (but not always) "undefined behavior." In languages like Rust, or Python, or Go, the answer is often (but not always) "the process quits." The reality is more complicated than that, but those are a fine first approximation. For example, breaking a runtime invariant doesn't have to lead to undefined behavior or process termination. It can simply result in a logic error that leads to unexpected behavior. Of course, making the issue more complicated is that sometimes 'unwrap()' is abused. And indeed, sometimes it is used in cases where an error ought to be returned. I find this to be generally pretty rare in popular libraries. But the key point here is that you can't just say, "oh I see unwrap() in a library, so now I'm going to scream ABUSE!!!!" It's more complicated than that.
- blub 4y agoHow is it nonsense if you admit at the end (albeit after a straw-man of me allegedly screaming “abuse”) that it happens? Result is being sold on HN as a great solution to error handling while there’s several crates available which are needed to polish its rough edges, rough edges which have led to e.g. unwrap abuse in the past. It is tedious to shuffle around results, but this is never part of the sales pitch. And for those of us that don’t want to depend on all sorts of crates for the simplest things, that’s the reality. Re your reply “Maybe improve your reading comprehension. I said "(partial) nonsense." Therefore, some of what you said wasn't nonsense. But some is. What a fucking revelation.” Partial nonsense isn’t nonsense by definition, I believe, but I won’t dwell that point. I am surprised seeing a Rustacean being (mildly) offensive and even saying the f-word. I must say that I am proud of you, too many nowadays act like polite, pedantic robots. :-)
- deleted 4y ago[deleted]
- burntsushi 4y agoI didn't say "nonsense." I said "(partial) nonsense." If we use our powers of logical deduction, it therefore follows that I wasn't claiming that everything you said was nonsense. Hence the reason I added nuance to my comment, unlike yours. I'm trying to tease apart the convoluted mess you're making. You're aware of Brandolini's law, right? This is a microcosm of that. Some of what you're saying is bullshit, but not quite all of it, and aspects of it are rooted in truth and reasonable experiences. (For example, I also do not "depend on all sorts of crates for the simplest things.") My tactic is to present nuance. You come back to me and instead of actually engaging with the nuance, starting whinging about what's being "sold on HN." Yawn. > It is tedious to shuffle around results, but this is never part of the sales pitch. This is a good example. Your sentence starts with something that I wouldn't agree with as a general rule, but I could certainly see it being true in specific circumstances. And even then, I'd want to explore those circumstances. That is, is it really a property of `Result` that makes it tedious, or is the problem of error handling in that context itself? It could be either. But then you follow it up with whinging about "sales pitch." Are you talking about some kind of sales pitch put out by the Rust project? Because if so, please link it to me. Or are you talking about a bunch of random HN commentators that can be overzealous about just literally anything? I don't see anyone saying Result is the best thing since sliced bread. What I do see are people describing positive experiences with it, especially in relationship to alternative error handling paradigms. Is that really a sales pitch? I mean, look at my top-level comment in this entire post. I sang the praise of sum types, and I did it by echoing what the OP said. Is that a sales pitch? Am I saying that sum types are the "best" at something? Am I saying that they have literally no costs at all? Am I saying that useful programs can't be written without sum types? Am I saying that all languages should be designed to include sum types? No. No. No. No and no. Did some other people go a touch too bar and make broad pronouncements about "correct" language design? Oh yeah, absolutely. Are those people some kind of singular phenomenon unique to Rust? Fuck no. And it is absolutely fucking baffling that I need to explain that to someone who has been on HN for as long as you have. This observation is so banal that it's blub.