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

Replace unwraps with expects in bevy_pbr #4046

Closed
wants to merge 14 commits into from

Conversation

omarbassam88
Copy link

Objective

Solution

  • Replacing all the unwraps with more helpful error messages.

@github-actions github-actions bot added the S-Needs-Triage This issue needs to be labelled label Feb 26, 2022
@ghost ghost mentioned this pull request Feb 26, 2022
31 tasks
@ghost ghost added C-Code-Quality A section of code that is hard to understand or change C-Usability A simple quality-of-life change that makes Bevy easier to use and removed S-Needs-Triage This issue needs to be labelled labels Feb 26, 2022
@ghost
Copy link

ghost commented Feb 26, 2022

Something went wrong here. You have two commits (Fix mesh2d_manual example and Fix unnecessary casts) that have nothing to do with this PR. Could you please remove those commits so that you only have your Replaced unwraps for bevy_pbr crate in there? Thanks.

@omarbassam88
Copy link
Author

Something went wrong here. You have two commits (Fix mesh2d_manual example and Fix unnecessary casts) that have nothing to do with this PR. Could you please remove those commits so that you only have your Replaced unwraps for bevy_pbr crate in there? Thanks.

I did fix it now. Sorry, this is my first pull request.

@ghost
Copy link

ghost commented Feb 26, 2022

I did fix it now. Sorry, this is my first pull request.

Perfect, thanks! Don't worry about it it's all good :)

crates/bevy_pbr/src/lib.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/lib.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/lib.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/material.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/render/light.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/render/mesh.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/render/mesh.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/render/mesh.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/render/mesh.rs Outdated Show resolved Hide resolved
crates/bevy_pbr/src/render/mesh.rs Outdated Show resolved Hide resolved
@superdump
Copy link
Contributor

Good stuff by the way! I'm just clarifying some of the error messages a little. :)

omarbassam88 and others added 11 commits February 28, 2022 15:42
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
@omarbassam88
Copy link
Author

Good stuff by the way! I'm just clarifying some of the error messages a little. :)

Thank you for your suggestions. I did commit your suggestions except for the one about the display of primitive_topology_bits. I am not really sure how can I test it?

@superdump
Copy link
Contributor

Good stuff by the way! I'm just clarifying some of the error messages a little. :)

Thank you for your suggestions. I did commit your suggestions except for the one about the display of primitive_topology_bits. I am not really sure how can I test it?

I guess try println!(“{}”, primitive_topology_bits); and see what it prints and whether it makes sense. If that doesn’t work due to a missing Display trait implementation, then you can try ”{:?}” instead, which I am pretty confident works as I think I’ve used it for wgpu::Features which are also bitflags.

@omarbassam88
Copy link
Author

Good stuff by the way! I'm just clarifying some of the error messages a little. :)

Thank you for your suggestions. I did commit your suggestions except for the one about the display of primitive_topology_bits. I am not really sure how can I test it?

I guess try println!(“{}”, primitive_topology_bits); and see what it prints and whether it makes sense. If that doesn’t work due to a missing Display trait implementation, then you can try ”{:?}” instead, which I am pretty confident works as I think I’ve used it for wgpu::Features which are also bitflags.

Yes, what I actually meant was is there's a specific example or test that I can run that calls this function just to make sure that it displays correctly?

@superdump
Copy link
Contributor

Yes, what I actually meant was is there's a specific example or test that I can run that calls this function just to make sure that it displays correctly?

I don’t think this should fail so I unfortunately have no suggestion how to trigger the error case. That’s why I’m suggesting just testing separately that a print or panic with a particular format string works.

@omarbassam88
Copy link
Author

Yes, what I actually meant was is there's a specific example or test that I can run that calls this function just to make sure that it displays correctly?

I don’t think this should fail so I unfortunately have no suggestion how to trigger the error case. That’s why I’m suggesting just testing separately that a print or panic with a particular format string works.

Ok , I just tested it now with load_gltf example using println! and just {} and it works and prints a u8 number. so. I guess it should work fine for the panic! as well. right?

@superdump
Copy link
Contributor

Ok , I just tested it now with load_gltf example using println! and just {} and it works and prints a u8 number. so. I guess it should work fine for the panic! as well. right?

Ohhhhh, I'm sorry! primitive_topology_bits is a u32! D'oh. That was a thinko on my part. Consider it resolved.

@superdump
Copy link
Contributor

So, now it just needs updating on top of main.

@omarbassam88
Copy link
Author

So, now it just needs updating on top of main.

What do you mean by on top of main?

@omarbassam88
Copy link
Author

Ah you mean to update it in sync with the main branch?

let asset_server = world.get_resource::<AssetServer>().unwrap();
let render_device = world.get_resource::<RenderDevice>().unwrap();
let asset_server = world
.get_resource::<AssetServer>()
Copy link
Member

Choose a reason for hiding this comment

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

We should replace these with the new world.resource::<AssetServer>() methods to avoid the need for duplicate panic messages / improve ergonomics.

Copy link
Author

Choose a reason for hiding this comment

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

OK, Shall I do it in this pull request? or should this issue be resolved independently and across all other crates as well?

Copy link
Author

Choose a reason for hiding this comment

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

OK, Shall I do it in this pull request? or should this issue be resolved independently and across all other crates as well?

Copy link
Contributor

Choose a reason for hiding this comment

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

Personally I feel like there's no harm in merging this PR and then going through and changing get_resource() to resource() if that is the new(?) API to use. But it's up to @cart .

@ghost
Copy link

ghost commented Feb 28, 2022

Your latest commit (merging main into your branch) went wrong. You didn't resolve the merge conflicts the right way. #4047 removed a lot of unwraps which probably caused most of the merge conflicts. Like cart already suggested, we should use world.resource now instead of world.get_resource in most cases, because this version panics with a good error message.

@omarbassam88
Copy link
Author

Your latest commit (merging main into your branch) went wrong. You didn't resolve the merge conflicts the right way. #4047 removed a lot of unwraps which probably caused most of the merge conflicts. Like cart already suggested, we should use world.resource now instead of world.get_resource in most cases, because this version panics with a good error message.

Yes, got it I am working on updating it to main branch now.

@alice-i-cecile
Copy link
Member

Closing per discussion in #3899 <3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Code-Quality A section of code that is hard to understand or change C-Usability A simple quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking issue: Replace unwrap with expect
4 participants