Hacker News Reader

Comment by wiktor-k | Hacker News Reader

> That section briefly described that, broadly speaking, using unwrap() is okay if it’s in test/example code or when panicking indicates a bug.

I've come to the conclusion that even in tests unwraps look ugly. Especially in doc tests which serve as examples the code is better off using regular "?" that one would see in other parts of code. (that is: don't treat test code as a "worse" kind of code)

In Signstar we're using testresult which still panics under the hood (which is OK for tests) https://gitlab.archlinux.org/archlinux/signstar/-/blob/main/... but the rendered example looks a lot better: https://docs.rs/nethsm/latest/nethsm/enum.OpenPgpVersion.htm...

Note that I'm currently maintaining that crate but the design is described at https://www.bluxte.net/musings/2023/01/08/improving_failure_...

View on HN

I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.

If you use `assert` in tests, I don't understand why you wouldn't also prefer unwrap in this context.

I think it's also perfectly reasonable to use in a context like binary you run locally for private consumption, or for instance a serverless function which allows you to pinpoint the source of errors more easily in the logs.

It's not a good fit for cases where you do expect cases where the unwrap will fail, but it's a great fit for cases where you believe the unwrap should always succeed, as it allows you to pinpoint the cases where it fails.

I call unwrap a lot in unit tests where it feels obvious to me that this succeeds, so, if it doesn't that's a huge mistake and should definitely fail the test but I have no pre-existing description of what's wrong, it's just a big red flag that I'm wrong.

Fallible conversions that never fail in the tested scenario are an example - parsing "15/7" as a Rational is never going to fail, so unwrap(). Converting 0.125 into a Real is never going to fail, so unwrap(). In a doctest I would write at least the expect call, because in many contexts you should handle errors and this shows the reader what they ought to do, but in the unit test these errors should never happen, there's no value in extensive handling code for this case.

> I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.

Take a closer look at testresult since it also points directly at the exact line of failure (due to panics being used under hood) but looks nicer.

I agree that unwrap looks ugly. Sometimes I wish Rust had a ! operator like Swift and TypeScript do. But then that would encourage bad practises in non-test code, so…

> but the rendered example looks a lot better:

For doctests it makes total sense, but for regular test no so much.

Reply on news.ycombinator.com