Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's already in the box... there's a bunch of options from unwrap_or, etc... to actually checking the error result and dealing with it cleanly... that's not what happened.

Not to mention the possibility of just bumping up through Result<> chaining with an app specific error model. The author chose neither... likely because they want the app to crash/reload from an external service. This is often the best approach to an indeterminate or unusable state/configuration.



> This is often the best approach to an indeterminate or unusable state/configuration.

The engineers had more semantic tools at their disposal for this than a bare `unwrap()`.

This was a systems failure. A better set of tools in Rust would have helped mitigate some of the blow.

`unwrap()` is from pre-1.0 Rust, before many of the type system-enabled error safety features existed. And certainly before many of the idiomatic syntactic sugars were put into place.

I posted in another thread that Rust should grow annotation features to allow us to statically rid or minimize our codebase of panic behavior. Outside of malloc failures, we should be able to constrain or rid large classes of them with something like this:

    panic fn my_panicky_function() {
      None.unwrap(); // NB: `unwrap()` is also marked `panic` in stdlib 
    }

    fn my_safe_function() {
      // with a certain compiler or Crates flag, this would fail to compile
      // as my_safe_function isn't annotated as `panic`
      my_panicky_function() 
    }
Obviously just an idea, but something like this would be nice. We should be able to do more than just linting, and we should have tools that guarantee transitive dependencies can't blow off our feet with panic shotguns.

In any case, until something is done, this is not the last time we'll hear unwrap() horror stories.


What you're suggesting is perfectly reasonable, I wouldn't object to labeling methods that can panic via bare unwrap...

I'm just saying that having a program immediately exit (via panic or not) could very well be the appropriate behavior.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: