Unify system and command error handling

[alice-i-cecile]

But it's weird that this is not unified with the system result handler

Hmm yeah we should think about how to unify these. I think applying the global handler to the system result handler by default makes some sense. I'd prefer that we tackle unification in a separate PR though.

I had some idea that we could be returning these errors to the scheduler through the sync-point system, idk if that's a viable.

Worth considering all of our options. Imo the direct handler approach is nice because it gives us both granularity and nice performance (no need to queue results up, look up which handler to use, etc). I think we should start from there with essentially optimal performance and then compare against the fancier options later.

I don't really think this will be a niche feature though. Don't we anticipate the editor using custom error handling to populate an error console? But that's nothing to do with the implementation

Hmmm yeah thats true. Although thats an implementation we'd own ourselves, and editor integration would likely be behind a cargo feature (so we could abstract that out from a user perspective). I think the majority of users shouldn't need to explicitly think about custom global error handlers.

Originally posted by @cart in #17215 (comment)

[alice-i-cecile]

System error handling:

• found in bevy_ecs::error module
• globally configured via DefaultSystemErrorHandler resource, which has App and Subapp helper methods
• locally configured via system piping
• handler is of the form fn(BevyError, SystemErrorContext)

Command error handling:

• found in bevy_ecs::system::commands module
• globally configured via the GLOBAL_ERROR_HANDLER OnceLock, which needs the configurable_error_handler feature to be enabled
• locally configured via EntityCommands::queue_handled
• handler is of the form fn(&mut World, BevyError)

Proposal:

• centralized in the bevy_ecs::error module
• globally configured by setting the DefaultErrorHandler resource, with no helper methods (one way to do this please)
• locally configured via system piping or queue_handled
• handler is of the form fn(&mut World, BevyError, EcsErrorContext)

[cart]

One consideration here is Observer error handling (which also uses fn(BevyError, SystemErrorContext)), which is executed with only DeferredWorld access.

[NthTensor]

It wouldn't be too terrible to make all error handling use deferred access. I doubt making structural changes to the world after an error will be common practice, and commands would be fine for that.

[alice-i-cecile]

Poking at this, the hard bits appear to be:

• passing in the default error handler to commands: I think this needs to be completely re-architected
• allowing for &mut World or DeferredWorld access: there's a lot of different executors, each with their own constraints and signatures

[cart]

passing in the default error handler to commands: I think this needs to be completely re-architected

Before making changes here, please see this context: #17215. (namely (4) and (5))

[alice-i-cecile]

Indeed. I've been thinking about this more and I'm not seeing a good branchless way to modify the commands design. We may need to standardize on the commands design instead.