-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow systems to return results #8705
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like this, but it's hard to discover. Can you add a quick handling_errors_in_systems
example in bevy_ecs
that demonstrates this, one of the built in logging adaptors and a custom adaptor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit then LGTM.
Co-authored-by: Alice Cecile <[email protected]>
I'm closing this out. Using If anyone finds a way of improving the panic message reporting, feel free to make a new PR based off of this. |
Objective
When writing an app in rust, the
main
function usually returns nothing, but it can also return aResult
; when doing this, returning anErr
value will result in a panic. This makes writing fallible code much more ergonomic, since?
can be used to propagate errors.This flexibility should be extended to systems: users should be able to return a
Result
from their systems. This can be done by callingsystem.pipe(unwrap)
when adding the system, however this approach requires more boilerplate, incurs a runtime overhead due to thePipeSystem
, removes context from the error message (since the panic message has no way of accessing the system's name), and makes the name of the combined system messier (which is stored by allocating a newString
).Solution
A system can only be added to a schedule if it implements
IntoSystemConfigs<>
. Currently, this is only implemented for systems that take no input and return nothing. Now, this trait is also implemented for any systems that returnResult<(), impl Debug>
. A custom system adapter is used that panics when the system returns an error and includes the system name in the message.Initially, I was concerned that this may make the compile error for systems with invalid return types more confusing. However in my testing, the error message does not seem to be any worse.
Changelog
Result<(), E>
, whereE
is any type that implementsstd::fmt::Debug
.