Yes it is. Typically you’d do some pattern matching to handle every possible case, but Unwrap is often used as a shortcut.

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.

It’s more like a method that can throw an exception. Rust doesn’t really have exceptions, but if you have a Result<T> or Option<T> type you can Unwrap it to get just the T. But if there’s no T to get (in the case of an Error type for Result for None for Option) the call panics.