Pass panics to the fallback error handler by SpecificProtagonist · Pull Request #24240 · bevyengine/bevy

SpecificProtagonist · 2026-05-11T10:29:16Z

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 · 2026-05-11T10:35:11Z

+                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.


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 · 2026-05-11T10:36:52Z

+                Err(_) => {
+                    let err = BevyError::new_with_backtrace(
+                        Severity::Panic,
+                        "System panicked",


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 · 2026-05-13T15:17:01Z

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 · 2026-05-17T03:02:55Z

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 · 2026-05-17T07:56:31Z

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.

Co-authored-by: Gonçalo Rica Pais da Silva <bluefinger@gmail.com>

resolved

# Objective Improve the handling of commands that panic. Currently, if a command panics, any unapplied commands are left in the command queue. This means they will get run, but at an unpredictable time in the future. And when running in `no_std`, cleanup is not run at all and the commands simply leak. ## Solution Catch panics from commands and pass them to the fallback error handler, just as we now do for systems from bevyengine#24240. This means if the error handler is set to something non-panicking like `warn`, then `flush_commands()` will never panic and all commands in the queue will be applied. Introduce a RAII guard during command application that will drop any commands still in the queue and perform cleanup during unwinding, even on `no_std`. To make the command's type name available in the error handler, add a field to the RAII guard that gets written by `consume_command_and_get_size` before applying the command.

SpecificProtagonist added 3 commits May 11, 2026 01:08

Pass system panics to fallback error handler

cbcbd32

Prevent panic thrown by error handler from being turned back into error

48d752f

tests

cc1e79a

SpecificProtagonist added C-Feature A new feature, making something new possible A-ECS Entities, components, systems, and events S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels May 11, 2026

github-project-automation Bot added this to ECS May 11, 2026

github-project-automation Bot moved this to Needs SME Triage in ECS May 11, 2026

typos

42448e3

SpecificProtagonist commented May 11, 2026

View reviewed changes

SpecificProtagonist added 2 commits May 11, 2026 12:39

import from alloc in test too

c34223a

import from alloc in test too

19664eb

SpecificProtagonist commented May 11, 2026

View reviewed changes

Comment thread crates/bevy_ecs/src/error/handler.rs

SpecificProtagonist added 2 commits May 11, 2026 12:58

no_std compile

34a1c43

remove dead code on no_std

f38fb5f

chescock reviewed May 11, 2026

View reviewed changes

Comment thread crates/bevy_ecs/src/schedule/executor/multi_threaded.rs Outdated

Comment thread crates/bevy_ecs/src/schedule/executor/multi_threaded.rs Outdated

Comment thread crates/bevy_ecs/src/schedule/executor/multi_threaded.rs Outdated

SpecificProtagonist added 2 commits May 11, 2026 22:15

simplify implementation

88d2a98

use provided error handler

401d514

SpecificProtagonist requested a review from chescock May 11, 2026 20:27

SpecificProtagonist added 6 commits May 11, 2026 22:38

no unused on no_std

321e3f1

test: unify payload recovery

b646d41

Reset panic origin flag in case of an outer catch_unwind

1a55046

make error handler panic flag logic slightly more readable

2df1504

drat, no_std strikes again

ee774f0

…import from core

ac19f64

alice-i-cecile requested a review from NthTensor May 13, 2026 15:16

alice-i-cecile added the M-Release-Note Work that should be called out in the blog due to impact label May 13, 2026

chescock approved these changes May 13, 2026

View reviewed changes

Comment thread crates/bevy_ecs/src/schedule/executor/multi_threaded.rs Outdated

SpecificProtagonist added 5 commits May 13, 2026 20:25

import BoxedSystem

af00b87

release notes

9901756

doc

6d610b9

typo

9ecc61d

…import…

34726af

run conditions

ee2d5e7

now with extra tests

a4f557d

Bluefinger reviewed May 22, 2026

View reviewed changes

Comment thread _release-content/release-notes/panics-to-errors.md Outdated

Bluefinger reviewed May 22, 2026

View reviewed changes

Comment thread _release-content/release-notes/panics-to-errors.md Outdated

SpecificProtagonist and others added 2 commits May 22, 2026 12:11

Update _release-content/release-notes/panics-to-errors.md

44d0ac5

Co-authored-by: Gonçalo Rica Pais da Silva <bluefinger@gmail.com>

Update _release-content/release-notes/panics-to-errors.md

6a86b6b

Co-authored-by: Gonçalo Rica Pais da Silva <bluefinger@gmail.com>

Bluefinger approved these changes May 22, 2026

View reviewed changes

SpecificProtagonist added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels May 22, 2026

mockersf previously requested changes May 22, 2026

View reviewed changes

Comment thread _release-content/release-notes/panics-to-errors.md Outdated

release note title

1ba41a1

SpecificProtagonist requested a review from mockersf May 22, 2026 14:18

alice-i-cecile enabled auto-merge May 24, 2026 08:55

alice-i-cecile added this pull request to the merge queue Jun 1, 2026

Merged via the queue into bevyengine:main with commit 18d106d Jun 1, 2026
38 checks passed

github-project-automation Bot moved this from Needs SME Triage to Done in ECS Jun 1, 2026

chescock mentioned this pull request Jul 7, 2026

Pass command panics to the fallback error handler #24911

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Pass panics to the fallback error handler#24240

Pass panics to the fallback error handler#24240
alice-i-cecile merged 26 commits into
bevyengine:mainfrom
SpecificProtagonist:panic-to-error

SpecificProtagonist commented May 11, 2026 •

edited

Loading

Uh oh!

SpecificProtagonist May 11, 2026

Uh oh!

SpecificProtagonist May 11, 2026 •

edited

Loading

Uh oh!

Uh oh!

chescock left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 13, 2026

Uh oh!

chescock left a comment

Uh oh!

Uh oh!

chescock commented May 17, 2026

Uh oh!

SpecificProtagonist commented May 17, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

SpecificProtagonist commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Why does Godot not use exceptions?

Solution

Testing

Uh oh!

SpecificProtagonist May 11, 2026

Choose a reason for hiding this comment

Uh oh!

SpecificProtagonist May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

chescock left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 13, 2026

Uh oh!

chescock left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

chescock commented May 17, 2026

Uh oh!

SpecificProtagonist commented May 17, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

SpecificProtagonist commented May 11, 2026 •

edited

Loading

SpecificProtagonist May 11, 2026 •

edited

Loading