[Feature Request] Extend AppExit::Error(NonZero<u8>) to AppExit::Error(NonZero<u8>, Option<String>))

[TheCGDF]

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

An u8 often cannot describe the error well.

It will be helpfull if allowing to insert an `Option' for error message.

Especially for who need to call update() and handle error manually.

What solution would you like?

Extend AppExit::Error(NonZero<u8>) to AppExit::Error(NonZero<u8>, Option<String>))

What alternative(s) have you considered?

Add a new AppExit::Error(String).

[mansiverma897993]

@TheCGDF I have raise #24751 addresing this issue plz look at once and lemme know if any changes required !

[TheCGDF]

@mansiverma897993 It looks nice! Will it be better if adding a pub const fn from_message(code: u8, message: impl Display) to simplify calling?

AppExit::from_message(1u8, "internal_server_error"); // no necessary to write `Some(...)` or `to_string()` here

[copygirl]

If intended to be inspected by the program, I feel like a Result would make more sense. However I feel like AppExit is only meant to be a mechanism to be able to return an error code from the application in case there is a reason for different error codes, at the operation system level, which only really supports error codes across the board, if at all. (stderr can be used in addition but you can write to that manually and there's even less standardization.) Bevy already has ways to deal with errors in systems that can (I think) optionally log and exit the app. This change could be misleading. Can you explain the need for this a bit more for me?

[TheCGDF]

I feel like AppExit is only meant to be a mechanism ... for different error codes, at the operation system level...

For client development, it is true. But when developing game servers, game server may hold many bevy apps at the same time (one bevy app for each player), and this error code will never be sent to OS (obviously server cannot exit like client). Also, there still be many things need to be done after bevy app exit (such as saving the latest player data to database).

Inevitably, game server need to send an error message to client to explain why it has to disconnect. The AppExit message will be a good way to make a conclusion for the reason because no update is running at the same time, this is the only&final message and cannot be edited/override like a Res.

I also created an issue #24568 to request making update() return Result<> but it seems to be difficult to change current bevy design. AppExit message will be a very quick workaround.

I'm still learning bevy, my mind may be stupid, don't hesitate to tell me if there is better choice.🙂

[copygirl]

Found a related discussion: #7067

I was expecting to be able to access resources after the app has completed running, but this doesn't seem to work:

use bevy::prelude::*;

#[derive(Resource)]
struct ExitMessage(pub String);

fn main() {
    let mut app = App::new();
    app.add_plugins(MinimalPlugins);
    app.add_systems(Update, exit_immediately);
    app.run();

    let msg = app.world().get_resource::<ExitMessage>();
    let reason = msg.map(|e| e.0.as_str()).unwrap_or("(none)");
    eprintln!("Exit reason: {reason}");
}

fn exit_immediately(mut commands: Commands, mut exit: MessageWriter<AppExit>) {
    commands.insert_resource(ExitMessage("exiting immediately!".into()));
    exit.write(AppExit::Success);
}

Exit reason: (none)

Unsure if the queued command resource insert doesn't get run because the app exits anyway, or what.

[TheCGDF]

Unsure if the queued command resource insert doesn't get run because the app exits anyway, or what.

Resources will be dropped immediately upon exit (I don't know why it's so urgent), so no resource can be found there and get_resource() should never be called after AppExit. This can be confirmed from document.