Pass panics to the fallback error handler

[SpecificProtagonist]

Objective

Currently, a panic (whether from engine or user code, as there is little distinction) takes down the entire app with it. Instead the user should be able to decide how the error is handled. This is currently not possible except by writing your own executor and setting it for all relevant schedules.

See for comparison Godot's policy on exceptions:

Why does Godot not use exceptions?

We believe games should not crash, no matter what. If an unexpected situation happens, Godot > will print an error (which can be traced even to script), but then it will try to recover as > gracefully as possible and keep going.

Unity will also log an error and then continue if user code throws an exception. I believe Unreal does too for exceptions coming from Blueprints. Similarly, many web servers will respond with an error to a request that threw an exception, but will not crash the server itself.

This PR does not enable this behavior by default, but makes it user-configurable.

Also fixes #19109
Also (I think) fixes #7434

Solution

Instead of rethrowing panics, hand them to the FallbackErrorHandler.

If the panic was thrown by an error handler in the first place, we don't need to pass it back to a handler again. I've added a way for the error handler to signal that it's the source of the panic.

The constructed error is created without a backtrace, as the default panic handler already prints it when instructed to via RUST_LIB_BACKTRACE/RUST_BACKTRACE.

Panics will not be turned into errors on no_std projects.

Potential work for a future PR:

• if a error handler has been specified with e.g. queue_handled, use this error handler instead of the fallback error handler
• if a command panics, still apply the remaining commands in the buffer?

Testing

See added panic_to_error test

[SpecificProtagonist]

By default, the panic handler will have already printed the panic payload, but we could add it to the error message given to the error handler too.

[SpecificProtagonist]

I'm using only an error message here, but if desired I could create a structured error that can be BevyError::downcast_refed.

Edit: The panic payload isn't Sync, so it can't be included in the error type, so this wouldn't be particularly useful

[chescock]

Yeah, being able to recover from panics seems like a really important part of making Bevy robust!

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[chescock]

Thanks, this version was much easier for me to follow!

[chescock]

Oh, I just remembered run conditions! Do we need to do something similar for them? I don't think we even catch_unwind them, so I have no idea what happens if they panic.

[SpecificProtagonist]

Good catch. I think that's because before #11906 they were evaluated in the executor task. I'm not sure whether the original reason for the catch_unwinds (#7448) still holds after that PR anyways.