• sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    6 hours ago

    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.

    • calcopiritus@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 hours ago

      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.