`BevyError` should include error severity to allow for customizable handling

[alice-i-cecile]

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

As we've shifted towards error handling across the engine, the number of panics has gone down! Yay!

Unfortunately, this is only really true if you do not use the default error handler, which panics by default. Boo!

This is particularly annoying in library code, as relatively harmless problems like inserting a component into a despawned entity are escalated into sudden crashes.

Users can configure

What solution would you like?

We should have some way of annotating the severity level of various problems, plumbing those problems through to BevyError. I'm not sure of the optimal strategy for doing so, but something like this feels right to me:

trait ErrorSeverity: Error {

    fn severity(&self) -> SeverityLevel {
          ErrorSeverity::Critical
    }
}

These can then be handled by the default error handler, causing it to log at the appropriate level, rather than immediately crashing.

We should also provide a "always panics" error handler for users who want the old behavior and are particularly performance sensitive. This error handler can be used on no_std platforms as needed as well.

What alternative(s) have you considered?

We could make possibly fallible operations fail silently. This is bad, because it masks potentially serious bugs in really frustrating ways.

We could log directly in our code, and return Ok. This is bad, because it's not robust to alternate logging solutions, and lies about the status of

We could add variants like try_insert everywhere, to make ignoring errors easier. This is bad, because it results in serious API duplication, complicating maintenance, and presents users with footguns.

Additional context

Discussed in #20544 with @NthTensor and @janhohenheim.

Related to #15979, #5617 and #17271.

[janhohenheim]

Also related to #19489: just because a Single is a failure doesn't mean it's an Error!

[Freyja-moth]

As a alternate proposal for how to do this.

Add a severity field onto BevyError and implement a with_serverity method onto Result<(), BevyError>

Which would allow for patterns such as this, without having to define custom error types for each situation.

fn check_stuff(player: Entity, sword_query: Query<&Sword>, head_query: Query<&Head>) -> Result {
    // This failing is completely normal, don't need to do anything about it.
    let player_sword = sword_query.get(player).with_severity(Severity::Ignore)?;

    // This, on the other hand, is decidedly not normal.
    let player_head = head_query.get(player).with_severity(Severity::Error)?;

    Ok(())
}

[Freyja-moth]

On further though this could likely be combined with @alice-i-cecile's trait idea by having the severity field be an Option<Severity> and use it to overwrite the severity received from the internal error.

[janhohenheim]

Note that the decision to panic or not should not lie with the function, but with the error handler. But other than that, I quite like the API you present :)

[Freyja-moth]

Good point, fixed the snippet.