-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(ecs): implement fallible observer systems #17731
Conversation
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]>
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]>
@alice-i-cecile I suppose we’ll want this for 0.16 as well? |
/// 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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay!
There was a problem hiding this 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); |
There was a problem hiding this comment.
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 😆
There was a problem hiding this 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]>
Resolved in 6e120a2. |
Signed-off-by: Jean Mertz <[email protected]>
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]>
Signed-off-by: Jean Mertz <[email protected]>
This PR has been rebased on main, and now incorporates the "configurable error handling for fallible systems" from #17753. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you!
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.