Pass panics to the fallback error handler#24240
Conversation
| Err(payload) if PANIC_ORIGINATES_FROM_ERROR_HANDLER.replace(false) => { | ||
| (None, Err(payload)) | ||
| } | ||
| // We can ignore the panic payload here, as it will have already been printed. |
There was a problem hiding this comment.
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.
| Err(_) => { | ||
| let err = BevyError::new_with_backtrace( | ||
| Severity::Panic, | ||
| "System panicked", |
There was a problem hiding this comment.
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
| /// When deliberately throwing a panic in your [`ErrorHandler`], | ||
| /// set this to true to indicate to the executor that the panic | ||
| /// should not be turned back into a [`BevyError`]. | ||
| pub static PANIC_ORIGINATES_FROM_ERROR_HANDLER: core::cell::Cell<bool> = const {core::cell::Cell::new(false)}; |
There was a problem hiding this comment.
This is not particularly elegant, but works and is easier to use than if for all error handlers we were to force a wrapper that set this to true, calls the error handler and then sets it to false again.
chescock
left a comment
There was a problem hiding this comment.
Yeah, being able to recover from panics seems like a really important part of making Bevy robust!
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:
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_stdprojects.Testing
See added
panic_to_errortest