search

nicopap / bevy_mod_sysfail

Decorate your bevy system with the sysfail macro attribute to make them handle cleanly failure mods.
Apache License 2.0
25 stars 5 forks source link

Provide a way to exit application on error #2

Closed janhohenheim closed 10 months ago

janhohenheim commented 1 year ago

Pretty much all of my code assumes that a system that returns an Err should probably result in the app terminating, e.g. assets that couldn't be loaded or some internal logic that broke API contracts. I don't use .expect() in these cases because I want to customize where the logs go, so bevy_mod_sysfail should be perfect for this. However, I don't think I can currently tell the crate to terminate on errors. In my mind, I've got some systems that should emit a Warn and go on and some others that should emit an Error and terminate. Maybe something along the following lines would be cool:

#[sysfail(log(exit))]
fn my_system_that_i_hope_does_not_err_or_we_got_a_problem_chief(...) -> Result<()> { ... }
nicopap commented 1 year ago

I think this crate needs a new design with the new bevy piping features. Basically the goal I have for this crate is that instead of defining handling in the app.add_systems(foo.pipe(error)) call, the piping is declared in the attribute macro for the system, so that the error handling is apparent where the system is defined. This would result also in flexibility enough for your use case I think.

The current implementation is "fine" for what I use it for (specifically I personally rely a lot on quick_sysfail for prototyping) but it doesn't quite solve what I set off to solve.

Though don't expect this to happen in the short term.