Per world error handler

[SpecificProtagonist]

Objective

see original comment

Alternately, could we store it on the World instead of a global? I think we have a World nearby whenever we call default_error_handler(). That would avoid the need for atomics or locks, since we could do ordinary reads and writes to the World.

Global error handlers don't actually need to be global – per world is enough. This allows using different handlers for different worlds and also removes the restrictions on changing the handler only once.

Solution

Each World can now store its own error handler in a resource.

For convenience, you can also set the default error handler for an App, which applies it to the worlds of all SubApps. The old behavior of only being able to set the error handler once is kept for apps.

We also don't need the configurable_error_handler feature anymore now.

Testing

New/adjusted tests for failing schedule systems & observers.

---

Showcase

App::new()
    .set_error_handler(info)
    …

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[SpecificProtagonist]

@alice-i-cecile Why the needs-benchmarking label? This doesn't do any synchronization at all because, not being global, it just uses normal Rust ownership. Also, as mentioned in #18801 (comment), we can't benchmark this well (unless there's just something screwed up with my computer and the relevant benchmarks are actually consistent enough for other people).

[Person-93]

For convenience, you can also set the default error handler for an App, which applies it to the worlds of all SubApps. The question is: What should happen when the default handler of those worlds gets set from elsewhere, either before or after insertion into the App respectively?

Perhaps it can be more than just a convenience. Maybe have a per-App and and a per-World handler, and if the World handler isn't set, it falls back on the App's handler.

[SpecificProtagonist]

Something to that effect could work, but bevy_ecs can't know about Apps.

Edit: I've solved this by keeping the old behavior of not letting the handler to be set multiple times (for an app).

[Person-93]

Something to that effect could work, but bevy_ecs can't know about Apps.

Perhaps a resource called AppErrorHandler with a function pointer, or a pointer-to-pointer.

[NthTensor]

@cart I want to make sure you see this pr too. Imo it's probably the direction we should go, rather than the atomics.

Still probably too late to slip in to 0.16 but maybe a bit less of a risk because there's no issues with platform support.