mirror of
https://github.com/bevyengine/bevy.git
synced 2026-07-01 00:05:45 -04:00
Mira
18d106d26a
# 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?](https://docs.godotengine.org/en/stable/about/faq.html#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 --------- Co-authored-by: Gonçalo Rica Pais da Silva <bluefinger@gmail.com>
791 B
791 B
title, authors, pull_requests
| title | authors | pull_requests | ||
|---|---|---|---|---|
| Catching Panics |
|
|
For long-running programs, crashing can be unacceptable. If, for example, there is a bug in one of your image editor's tools, it's better for that tool to fail or to produce wrong results than to lose all your unsaved work.
Bevy's systems, commands and observers are able to return errors. You can either set an error handler case-by-case, or let the FallbackErrorHandler deal with it. But this used to only work for explicitly returned errors: Panics used to bring down the entire app.
In Bevy 0.xx, these panics now get turned into errors and passed to the fallback error handler. By default this re-panics, but now you can choose whether to log an error and continue, or whatever else you want.