Fix window close in example cause panic

[jiangheng90]

Objective

Fixes #17532

Solution

• check window valide

[Selene-Amanita]

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

[Selene-Amanita]

Apparently the order in which Bevy does things is to allow people to write a system to react to an AppExit event in Update. I'm not sure this is right, but as long as it stays that way and Single panics, systems should probably never expect that there will always be a Window, and so the Single<&Window> should be reverted back. So, approving this PR. Might be needed for other examples too.

[beholdnec]

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

[BenjaminBrienen]

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

[jiangheng90]

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

[BenjaminBrienen]

Closing in favor of the other PR

[mockersf]

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

[jiangheng90]

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