Add the ability to attach context to `BevyError`

[Shatur]

What problem does this solve or what need does it fill?

I sometimes call functions inside Bevy systems that return errors. But in applications it's quite useful to have "layered" errors. For example:

Error: unable to apply replication.

Caused by:
    Unable to deserialize message for tick 14
    Unable to deserialize entity 1v4

What solution would you like?

It would be great something similar to anyhow - an extension trait on any result or option that attaches context.

What alternative(s) have you considered?

Format errors like this manually. But it's not very ergonomic.

[hukasu]

IIRC BevyError has a blanket impl for anything that has Error, which should include anyhow errors

[Shatur]

Yes, but this means I have to pull anyhow to have contextual errors.

[hukasu]

yes, but having it like this does not lock users to only anyhow, i myself prefer error-stack

[Shatur]

I'm not suggesting using anyhow. I propose extending the functionality of BevyError.

[hukasu]

IIRC the intend of BevyError was to be lightweight and flexible, not feature-rich

[Shatur]

I think the intend of BevyError is to create a more opinionated error type to operate on Bevy-specific context.
Contextual errors is quite important for games and I don't think we need to encourage users to use third-party error crates to convert them later into Bevy errors. It's simply not a great experience.

[hukasu]

#18144

The biggest reason is that anyhow needs to be a "generically useful error type", whereas Bevy is a much narrower scope.
...
Additionally, the core approach used is simple and requires almost no code. anyhow clocks in at ~2500 lines of code, but the impl here uses 160.

[hukasu]

i already exposed my understanding, now we wait for someone with deeper knowledge to continue the discussion

[Shatur]

Not a native speaker, but I understood the last paragraph of the PR differently. The idea is to create an error type coupled with Bevy and implement exactly what we need. And I'd say that attaching context is one of those things.

Another inconvenience of using a third-party error crate like anyhow is that we can't convert BevyError into anyhow::Error.

? couldn’t convert the error: BevyError: StdError is not satisfied
the question mark operation (?) implicitly performs a conversion on the error value using the From trait
required for anyhow::Error to implement From<BevyError> (rustc E0277)
hint: this has type `Result<_, BevyError>`

The conversion works only the other way around.

[hukasu]

What are the APIs that return a BevyError to the user currently?