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.

[cart]

Makes sense! And yeah I'd prefer to do this in 0.17

[chescock]

Why the needs-benchmarking label? This doesn't do any synchronization at all because, not being global, it just uses normal Rust ownership.

The get_resource() call does a hashtable lookup to convert the type to a ComponentId, so it's not completely free.

But since you changed it to only perform the lookup once per schedule or once per failing command, I'd be surprised if there were any measurable overhead!

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).

It's not just you; I also get lots of noise when I run the benchmarks.

[NthTensor]

Please remove the pr number from the migration guide file name. Otherwise this looks fantastic.

[alice-i-cecile]

I'm really glad to see a nice solution here. Now that I have the time to review it I'm on board with this as the way forward.

[NthTensor]

Looks like got conflicted out of the last merge train. It should be good to get these conflicts resolved before the next one.