Not all failures are able to be handled, or meaningful to be passed, in a manner other than panic.

Unwrap is useful in a lot of places where it can be statically proven that the unwrap can’t panic (for example, a pre-checked parse), and equally useful in places where the only possible resolution of a failure is termination.

If you’re encountering panics when consuming a library that shouldn’t be occurring, and have a reasonable way to handle them, then yeah; file an issue saying “hey, you’re aborting the process too early”

You can also establish the precondition yourself: if a library function panics on you and you need it to not do that, and have a way of dealing with failure, filter your calls to it. Before passing in a value that may induce failure, check it, and only call the function if it’s valid; if not, do your recovery process immediately rather than wait on the library to do its work and then fail.

Probably unwrap and expect should be limited to testing only and should be enforced by the compiler.

is simply untenable. The fastest way to get past this lint is to replace all .unwrap() with .or_else(|_| panic!()) , and now the lint passes and nothing has been gained.