`unwrap` considered harmful

[james7132]

What problem does this solve or what need does it fill?

Unwrap should generally be avoided. We already encourage contributors to avoid the use of Option::unwrap, yet crashes from panics are still one of the most common categories of issues we're seeing now.

What solution would you like?

• Enable the clippy unwrap_used lint at a workspace level, and add allow-unwrap-in-tests = true to Clippy.toml.
• Replace actual expected crashes with expect or unwrap_or_else with a panic where possible, otherwise properly gracefully handle the error.
• Preferably avoid panicking in the renderer entirely, instead failing gracefully where possible by logging a warning and not rendering anything or using blatantly obvious errors (i.e. Valve's missing texture shader).

What alternative(s) have you considered?

Leaving it as is. Keep crashing from unwraps.

Status

• bevy_animation
• bevy_app
• bevy_asset
• bevy_core_pipeline
• bevy_core_widgets
• bevy_derive
• bevy_diagnostic
• bevy_ecs
• bevy_ecs_macros
• bevy_gilrs
• bevy_gltf
• bevy_gizmos
• bevy_image
• bevy_input_focus
• bevy_light
• bevy_log
• bevy_macro_utils
• bevy_math
• bevy_mesh
• bevy_pbr
• bevy_post_process
• bevy_reflect
• bevy_reflect_derive
• bevy_render_macros
• bevy_scene
• bevy_shader
• bevy_sprite_render
• bevy_text
• bevy_transform
• bevy_ui
• bevy_ui_render
• bevy_window
• bevy_winit

[alice-i-cecile]

See #10166 for a major culprit.

[SludgePhD]

Another API design issue related to this is Query::single / Query::get_single – here, the shorter method name that users are most likely to go for will .unwrap() implicitly. IMO Query::single is almost never the right choice and just making it have the semantics of get_single would be better.

[alice-i-cecile]

single/get_single used to work like that: users at the time found it tedious to constantly check if their player or camera had despawned!

It was also moved to be consistent with .resource / .get_resource, which while it still panics is much less prone to unexpected failure, as removing resources is much more rare than despawning entities.

That said, I am personally allergic to using .single in my own serious projects due to frustrations with panics in edge cases and during refactors, and return early on errors.

[bushrat011899]

Perhaps instead of get_x and x, we could use x and x_unchecked instead? This makes the panicking API clearly distinguishable from the non-panicing, while also encouraging the idiomatic path.

Regardless, I agree with this change. unwrap is a code smell within a library.

[james7132]

x_unchecked makes my mind jump immediately to unsafe, which we shouldn't be encouraging unless it's paramount that users squeeze every last ounce of performance out.

[alice-i-cecile]

I think that x_unchecked (by whatever name) isn't worth adding. It's more API to maintain, and not actually much nicer than just another unwrap call.

[benfrankel]

Another source of panics is when systems with Res or ResMut arguments are scheduled when the resource doesn't exist. In complex applications this might be triggered only in very specific scenarios, making it difficult to catch by playtesting.

The alternatives off the top of my head are a little awkward, though:

1. If a system requires a resource that does not exist, skip that system and log a warning.
2. Require systems to use Option<Res> instead of Res, or give Res the same behavior as Option<Res> somehow.

[msvbg]

I would be in favor of renaming single to something like get_single_unchecked, or some other similarly clunky name, to discourage its use. Or it could be removed entirely. I've seen a fair few crashes coming from single.

[alice-i-cecile]

#1255 is a big source of dumb panics as I refactor as well.