While your PR fixes the issue from the point of view of the example, I feel like there's something wrong regarding how Bevy handles this that should probably be fixed.

In order, during a Main schedule/frame, Bevy:

1. in Update, will check if all windows have been closed (aka no entity with a Window component) with exit_on_all_closed and send an AppExit event if that's the case https://docs.rs/bevy/latest/bevy/window/fn.exit_on_all_closed.html
2. in Last, will despawn Window entities corresponding to a closed Window with despawn_windows

   bevy/crates/bevy_winit/src/lib.rs

   Line 134 in deb135c

   despawn_windows,

   /

   bevy/crates/bevy_winit/src/system.rs

   Line 205 in deb135c

   pub(crate) fn despawn_windows(

3. at the end of the schedule in bevy_winit will check if an AppExit even has been sent to stop the app

I feel like step 1 should be done between 2 and 3, to avoid having a frame where the Window entity is despawned despite Bevy being configured to exit when that happens. So exit_on_all_closed (and exit_on_primary_closed) should be ordered in Last after despawn_windows (and a flush of the despawns). But maybe I'm missing something? Maybe it's not done that way because it messes with parallelization in the Last schedule, or maybe Bevy does expect to have one frame to deal with the no-window scenario for whatever reason?

I expect the same panic occuring in other examples using the Single<&Window> pattern: https://github.com/search?q=repo%3Abevyengine%2Fbevy+Single%3C%26Window%3E&type=code

I think this is the same issue I reported here: #16066

This doesn't seem right to me. The problem at hand is a general one. We shouldn't have to validate parameters like this.

@Selene-Amanita @BenjaminBrienen I have fix this problem in #17543

Closing in favor of the other PR

Single is not really usable until we've added back non panicking parameter validation. until then it should be avoided, like this PR does

I just have changed Single<&Window>, which will call in update and cause panic. not all of it.