“Rust is safe” is not some kind of absolute guarantee of code safety

Re:“Rust is safe” is not some kind of absolute guarantee of ... by oconnor663 on Sunday October 02, 2022 @12:55PM (#33057741)

I don't have any experience with this project, but I know a lot of panics in my Rust code look like this (you probably know this already, just setting up a question):

    fn foo<T>() -> Option<T> {
        // Oops, something went wrong and we don't have a T.
        None
    }

    fn bar<T>() -> T {
        if let Some(t) = foo() {
            t
        } else {
            // This could've been an `unwrap`; just being explicit here
            panic!("oh no!");
        }
    }

A panic in this case is exactly like an exception in that the function that's failing doesn't need to come up with a return value. Unwinding happens instead of returning anything. But if I was writing `bar` and I was trying to follow a policy like "never unwind, always return something", I'd be in a real pickle, because the way the underlying `foo` function is designed, there aren't any T's sitting around for me to return. Should I conjure one out of thin air / uninitialized memory? What does the kernel do in situations like this? I guess the ideal solution is making `bar` return `Option<T>` instead of `T`, but I don't imagine that's always possible?

[ Parent | on HN ]

Re:“Rust is safe” is not some kind of absolute guarantee of ... by strictfp on Sunday October 02, 2022 @12:59PM (#33057789)

The harsh truth is that you need to think about every single case of failure, and decide what to do when things go south.

If you look at how POSIX does it, pretty much every single function has error codes, signaling everything from lost connections, to running out of memory, entropy or whatnot. Failures are hard to abstract away. Unless you have some real viable fallback to use, you're going to have to tell the user that something went wrong and leave it up to them to decide what the application can best do in this case.

So in your case, I would return Result<T>, and encode the errors in that. Simply expose the problem to the caller.

[ Parent | on HN ]

Re:“Rust is safe” is not some kind of absolute guarantee of ... by jmillikin on Sunday October 02, 2022 @01:01PM (#33057811)

Couple options:

1. Have a constraint on T that lets you return some sort of placeholder. For example, if you've got an array of u8, maybe every read past the end of the array returns 0.

  fn bar<T: Default>() -> T {
    if let Some(t) = foo() {
      t
    } else {
      eprintln!("programmer error, foo() returned None!");
      Default::default()
    }
  }

2. Return a `Option<T>` from bar, as you describe.

3. Return a `Result<T, BarError>`, where `BarError` is a struct or enum describing possible error conditions.

  #[non_exhaustive]
  enum BarError {
    FooIsNone,
  }
  
  fn bar<T>() -> Result<T, BarError> {
    if let Some(t) = foo() {
      Ok(t)
    } else {
      eprintln!("programmer error, foo() returned None!");
      Err(BarError::FooIsNone)
    }
  }

[ Parent | on HN ]