Skip to content

Improve error message for missing events #18683

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

Merged
merged 4 commits into from
Apr 2, 2025

Conversation

chescock
Copy link
Contributor

@chescock chescock commented Apr 2, 2025

Objective

Improve the parameter validation error message for Event(Reader|Writer|Mutator).

System parameters defined using #[derive(SystemParam)], including the parameters for events, currently propagate the validation errors from their subparameters. The error includes the type of the failing parameter, so the resulting error includes the type of the failing subparameter instead of the derived parameter.

In particular, EventReader<T> will report an error from a Res<Events<T>>, even though the user has no parameter of that type!

This is a follow-up to #18593.

Solution

Have #[derive]d system parameters map errors during propagation so that they report the outer parameter type.

To continue to provide context, add a field to SystemParamValidationError that identifies the subparameter by name, and is empty for non-#[derive]d parameters.

Allow them to override the failure message for individual parameters. Use this to convert "Resource does not exist" to "Event not initialized" for Event(Reader|Writer|Mutator).

Showcase

The validation error for a EventReader<SomeEvent> parameter when add_event has not been called changes from:

Before:

Parameter `Res<Events<SomeEvent>>` failed validation: Resource does not exist

After

Parameter `EventReader<SomeEvent>::events` failed validation: Event not initialized

@alice-i-cecile alice-i-cecile added this to the 0.16 milestone Apr 2, 2025
@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use X-Uncontroversial This work is generally agreed upon D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Apr 2, 2025
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lovely! @Bleachfuel, would you be able to give me a quick review here? I've really appreciated your macro expertise.

@alice-i-cecile alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Apr 2, 2025
Copy link
Contributor

@Bleachfuel Bleachfuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! However maybe we should merge #18199 first as it makes this code more reasonable, since we now are doing all kinds of stuff inside one iter()

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Apr 2, 2025
Merged via the queue into bevyengine:main with commit 9e240ee Apr 2, 2025
45 checks passed
mockersf pushed a commit that referenced this pull request Apr 3, 2025
# Objective

Improve the parameter validation error message for
`Event(Reader|Writer|Mutator)`.

System parameters defined using `#[derive(SystemParam)]`, including the
parameters for events, currently propagate the validation errors from
their subparameters. The error includes the type of the failing
parameter, so the resulting error includes the type of the failing
subparameter instead of the derived parameter.

In particular, `EventReader<T>` will report an error from a
`Res<Events<T>>`, even though the user has no parameter of that type!

This is a follow-up to #18593.

## Solution

Have `#[derive]`d system parameters map errors during propagation so
that they report the outer parameter type.

To continue to provide context, add a field to
`SystemParamValidationError` that identifies the subparameter by name,
and is empty for non-`#[derive]`d parameters.

Allow them to override the failure message for individual parameters.
Use this to convert "Resource does not exist" to "Event not initialized"
for `Event(Reader|Writer|Mutator)`.

## Showcase

The validation error for a `EventReader<SomeEvent>` parameter when
`add_event` has not been called changes from:

Before: 
```
Parameter `Res<Events<SomeEvent>>` failed validation: Resource does not exist
```

After
```
Parameter `EventReader<SomeEvent>::events` failed validation: Event not initialized
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Uncontroversial This work is generally agreed upon
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants