Skip to content
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

Return missing component types in QueryDoesNotMatch errors #8917

Open
SignalWalker opened this issue Jun 21, 2023 · 1 comment · May be fixed by #9041
Open

Return missing component types in QueryDoesNotMatch errors #8917

SignalWalker opened this issue Jun 21, 2023 · 1 comment · May be fixed by #9041
Labels
A-Diagnostics Logging, crash handling, error reporting and performance analysis A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use

Comments

@SignalWalker
Copy link

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

When handling QueryEntityError::QueryDoesNotMatch from Querys over multiple component types, it'd be useful for debugging to be able to check which components were missing.

What solution would you like?

The first that comes to mind is to just put a Vec of component names in the error type, but it doesn't have to be that -- I just want to be able to find out without having to manually check each component. Maybe a Query::get_missing function?

What alternative(s) have you considered?

  • Instead of Query<(X, Y)>, use Query<(Option<X>, Option<Y>)> -- this isn't very ergonomic, though, especially when the component isn't actually intended to be optional.

Related PRs

@SignalWalker SignalWalker added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jun 21, 2023
@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 and removed C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jun 21, 2023
@Selene-Amanita
Copy link
Member

Selene-Amanita commented Jun 21, 2023

Additionally, those "Query[Something]Error" types could return more informations on other cases:

  • QueryComponentError variants could contain the Entity that was requested, like QueryEntityError variants do
  • QueryComponentError variants could contain a representation of the Component that was requested
  • QueryComponentError variants and QueryEntityError variants could contain a &str representation of the query, like QuerySingleError variants do, using std::any::type_name()
  • I realize now that I didn't document that QueryEntityError contain the Entity and QuerySingleErrorcontain a &str of the query in Document query errors #8692.

Those are less useful (and technically an other issue) because technically you should know those informations (/have them at hand) when you write the code and call the function that triggers them, contrary to knowing what went wrong with QueryEntityError::QueryDoesNotMatch which is what that PR is about, but having those additional informations inside the "Query[Something]Error" types could allow to have a function that handles error from different parts of the code.

Note: the &str variant of the query could be replaced by a generic type of the error, to avoid processing it and storing it if not needed, but would probably increase the compilation time/size of the binary for no reason.

@Selene-Amanita Selene-Amanita added the A-Diagnostics Logging, crash handling, error reporting and performance analysis label Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Diagnostics Logging, crash handling, error reporting and performance analysis A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants