this post was submitted on 18 Dec 2025
253 points (98.8% liked)

Programmer Humor

39521 readers
491 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] hades@feddit.uk 73 points 20 hours ago (13 children)

can you explain the joke, i work at cloudflare

[–] mkwt@lemmy.world 33 points 20 hours ago (11 children)

Rust has many container-like objects that may or may contain a value, like Box. Most of these have an unwrap() method that either obtains the inner value or panics the whole application.

[–] TimeSquirrel@kbin.melroy.org 3 points 19 hours ago (6 children)

Is this just like the equivalent of a getter method in C++?

[–] balsoft@lemmy.ml 6 points 18 hours ago* (last edited 17 hours ago)

It's worse than just exceptions in C++. There's (almost) no way for the caller of your function to catch it. It's a bit like this snippet:

std::optional<int> foo = <...>;
try {
  return foo.value();
} catch(const std::bad_optional_access& e) {
  std::cout << e.what() << std::endl;
  abort();
}

It's the abort that is the crux of the issue here. Usually you would pass the std::optional up/down the call stack. If you don't control the types (e.g. using a library or a framework) you'd come up with some "default" value instead, like this:

std::optional<int> foo = <...>;
return foo.value_or(123);

Or in Rust:

let foo : Option<i32> = <...>;
return foo.unwrap_or(123);

But sometimes there's no good "default" value, and then you have to resort to just unwrap-ing the value, and accepting that the entire program will abort when that function call fails. Usually this is a sign of poor engineering somewhere, likely in a library you're using, and should be fixed; but sometimes you don't have the time to fix it, and then it ends up in production.

load more comments (5 replies)
load more comments (9 replies)
load more comments (10 replies)