feat(ecs): configurable error handling for fallible systems

[JeanMertz]

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.

[NthTensor]

Wonderful, thanks! I will try very hard to find the time to review this sometime this week.

[alice-i-cecile]

Basic strategy looks good to me. Exposing the different error handlers at the schedule level is definitely the most natural way to do this, even if I think that users will almost never set error handlers for specific schedules independently.

That said, I think we should:

1. Improve the documentation to more clearly explain the core model. The bevy_ecs::result module feels like the best place for a detailed explanation, which should be linked wherever these setters are exposed.
2. Cut the error handling setter from World: it's neither convenient nor natural, and it's super easy to implement externally.
3. Add a few conveniences to the result module to make setting this behavior to info/warn/error/ignore easier.

3 can easily happen in follow-up though :)

[JeanMertz]

edit applied the change in 5c30e11.

I realized #17731 does not give us access to ScheduleSystem (because observer systems aren't "scheduled" in the ECS the way regular systems are).

So it probably makes sense to review and merge #17731 first, then update this PR to change the error handler signature from fn(Error, &ScheduledSystem) to (e.g.) fn(Error, SystemErrorContext), which allows us to pass some context such as the system name for both scheduled systems and observer systems.

It also warrants a discussion on where our default error_handler should live. As I can fetch the Schedules resource to get the default error handler for observer systems, but for obvious reasons that's a weird place to get the data from.

Given that we're already doing a world.get_resource::<Schedules> to get the global error handler, I'm thinking we could instead introduce a new DefaultSystemsErrorHandler resource that we pull instead, both for scheduled systems and observer systems. That resource would be fetched once when initializing a schedule, or when spawning an observer, so it's not in any significantly hot path.

[alice-i-cecile]

Given that we're already doing a world.get_resource:: to get the global error handler, I'm thinking we could instead introduce a new DefaultSystemsErrorHandler resource that we pull instead, both for scheduled systems and observer systems. That resource would be fetched once when initializing a schedule, or when spawning an observer, so it's not in any significantly hot path.

I like this!

[cart]

I think this is the right approach. Well done!

[notmd]

Nice work, just small question. How does Rust Analyzer work with this when suggesting autocomplete? Does it conflict with the warn!, error macro etc from tracing? If it conflicts I think we should wrap them in a SystemErrorHandler struct. As this probably use one time so additional namespace is fine.

[JeanMertz]

Nice work, just small question. How does Rust Analyzer work with this when suggesting autocomplete? Does it conflict with the warn!, error macro etc from tracing? If it conflicts I think we should wrap them in a SystemErrorHandler struct. As this probably use one time so additional namespace is fine.

The bare functions aren’t exposed in the prelude, so it shouldn’t be an issue.

[alice-i-cecile]

Nice refinement!

[alice-i-cecile]

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1993 if you'd like to help out.