Skip to content

feat(ecs): implement fallible observer systems #17731

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Feb 11, 2025

Conversation

JeanMertz
Copy link
Contributor

This commit builds on top of the work done in #16589 and #17051, by adding support for fallible observer systems.

As with the previous work, the actual results of the observer system are suppressed for now, but the intention is to provide a way to handle errors in a global way.

Until then, you can use a PipeSystem to manually handle results.

This commit builds on top of the work done in bevyengine#16589 and bevyengine#17051, by
adding support for fallible observer systems.

As with the previous work, the actual results of the observer system
are suppressed by default, but the intention is to provide a way to
handle errors in a global way.

Until then, you can use a `PipeSystem` to manually handle results.

Signed-off-by: Jean Mertz <[email protected]>
JeanMertz added a commit to dcdpr/bevy that referenced this pull request Feb 9, 2025
You can now configure error handlers for fallible systems. These can be
configured on several levels:

- Globally via `App::set_systems_error_handler`
- Per-schedule via `Schedule::set_error_handler`
- Per-system via a piped system (this is existing functionality)

The "fallible_systems" example demonstrates the new functionality.

This builds on top of bevyengine#17731, bevyengine#16589, bevyengine#17051.

Signed-off-by: Jean Mertz <[email protected]>
@JeanMertz
Copy link
Contributor Author

@alice-i-cecile I suppose we’ll want this for 0.16 as well?

@alice-i-cecile alice-i-cecile added this to the 0.16 milestone Feb 9, 2025
@alice-i-cecile alice-i-cecile 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 Feb 9, 2025
/// An example of a system that calls several fallible functions with the questionmark operator.
/// An example of a system that calls several fallible functions with the question mark operator.
///
/// See: <https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-question-mark-operator>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay!

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So pretty :D And yeah, the design is nice and consistent with previous work.

@@ -386,7 +386,8 @@ fn observer_system_runner<E: Event, B: Bundle, S: ObserverSystem<E, B>>(
unsafe {
(*system).update_archetype_component_access(world);
if (*system).validate_param_unsafe(world) {
(*system).run_unsafe(trigger, world);
Copy link
Contributor

@Carter0 Carter0 Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading this block of code makes me feel like Im a kid running in the street 😆

Copy link
Contributor

@Carter0 Carter0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll come back to this later, but is it useful to write a test or two for this? It would make me feel more confident this is working correctly at least.

Signed-off-by: Jean Mertz <[email protected]>
Signed-off-by: Jean Mertz <[email protected]>
@JeanMertz
Copy link
Contributor Author

I'll come back to this later, but is it useful to write a test or two for this? It would make me feel more confident this is working correctly at least.

Resolved in 6e120a2.

github-merge-queue bot pushed a commit that referenced this pull request Feb 11, 2025
You can now configure error handlers for fallible systems. These can be
configured on several levels:

- Globally via `App::set_systems_error_handler`
- Per-schedule via `Schedule::set_error_handler`
- Per-system via a piped system (this is existing functionality)

The default handler of panicking on error keeps the same behavior as
before this commit.

The "fallible_systems" example demonstrates the new functionality.

This builds on top of #17731, #16589, #17051.

---------

Signed-off-by: Jean Mertz <[email protected]>
@JeanMertz
Copy link
Contributor Author

This PR has been rebased on main, and now incorporates the "configurable error handling for fallible systems" from #17753.

@alice-i-cecile alice-i-cecile added X-Uncontroversial This work is generally agreed upon D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes labels Feb 11, 2025
@alice-i-cecile alice-i-cecile 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 Feb 11, 2025
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Feb 11, 2025
Merged via the queue into bevyengine:main with commit 7d8504f Feb 11, 2025
36 checks passed
Copy link
Contributor

@Carter0 Carter0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Uncontroversial This work is generally agreed upon
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants