feat(ecs): implement fallible observer systems#17731
feat(ecs): implement fallible observer systems#17731alice-i-cecile merged 7 commits intobevyengine:mainfrom
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 <git@jeanmertz.com>
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 <git@jeanmertz.com>
|
@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> |
alice-i-cecile
left a comment
There was a problem hiding this comment.
So pretty :D And yeah, the design is nice and consistent with previous work.
| 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.
Reading this block of code makes me feel like Im a kid running in the street 😆
Carter0
left a comment
There was a problem hiding this comment.
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 <git@jeanmertz.com>
Signed-off-by: Jean Mertz <git@jeanmertz.com>
Resolved in 6e120a2. |
Signed-off-by: Jean Mertz <git@jeanmertz.com>
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 <git@jeanmertz.com>
Signed-off-by: Jean Mertz <git@jeanmertz.com>
|
This PR has been rebased on main, and now incorporates the "configurable error handling for fallible systems" from #17753. |
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
PipeSystemto manually handle results.