Change HandleUntyped::typed to not panic

[kroltan]

Objective

Fixes #2534

Solution

Changed the signature and implementation of HandleUntyped::typed to return a Result instead of panicking.

Adjusted a bunch of engine crate code that uses that function, but I sense a code smell. All usages are creating HandleUntypeds statically, and converting to Handle<T> on use. This could be avoided by just creating a Handle<T> in the first place.

I'll open another PR with that change.

[alice-i-cecile]

bors try

[bors]

try

Build failed:

• build (stable, ubuntu-latest)

[alice-i-cecile]

Adjusted a bunch of engine crate code that uses that function, but I sense a code smell. All usages are creating HandleUntypeds statically, and converting to Handle on use. This could be avoided by just creating a Handle in the first place.

@cart do you have insight on this? Will the new renderer changes alter this?

[kroltan]

Hmm seems I done a silly one and forgot to run cargo fmt.

[kroltan]

Actually I forgot to run the whole CI. Still some elbow grease to go on this one!

[kroltan]

@alice-i-cecile With this change, AssetServer::load changes to propagate the Result.

However this raises a further question, how come it wasn't a Result before? It seems that internally it goes to load_untracked that just yells a warning if the loading fails.

This feels like a big API change, so should I do the same and output a warning instead of changing the return type of AssetServer::load (leaving this interface change to another issue), or bite the bullet and change the interface?

(I didn't notice this earlier since I was being a silly man and forgot to run the CI that showed the actual scope of the change 😅)

[alice-i-cecile]

bors try

[bors]

try

Build failed:

• build (stable, ubuntu-latest)

[alice-i-cecile]

However this raises a further question, how come it wasn't a Result before? It seems that internally it goes to load_untracked that just yells a warning if the loading fails.

Hmm. I'm genuinely unsure. I know asset loading is deliberately async; maybe it's to avoid propagating results?

In any case, I think we should split this work out and create a new issue. The asset pipeline needs some serious design work in general (see #1701, #708) so it's better to tackle that more holistically.

[kroltan]

Actually, upon a bit more careful investigation, currently the error path would never trigger anyways. typed can only fail for HandleId::Id, not HandleId::AssetPathId, which is what the AssetServer code path uses.

Anyways, fixed the CI errors and reverted the AssetServer::load signature.

[mockersf]

This could be avoided by just creating a Handle<T> in the first place.

There isn't yet a const way to make a Handle<T>, but you can probably adapt

bevy/crates/bevy_asset/src/handle.rs

Line 244 in a4e5e27

pub const fn weak_from_u64(uuid: Uuid, id: u64) -> Self {

[kroltan]

There isn't yet a const way to make a Handle<T>

Yeah, you're right, I scratched up this change but it requires #![feature(const_fn_trait_bound)].

It could be revisited once that language feature get stabilized.

---

Regarding the contents of this PR, this should be ready for review.

[mockersf]

Regarding the contents of this PR, this should be ready for review.

Not a fan of the FIXME comments, could you reword them?

[kroltan]

How about this?

Handle is always converted to typed, see discussion in PR #2536

[mockersf]

Good for me! Thanks

[NathanSWard]

Curious, I'm pretty sure handle used to return a Result/Option type and then it got changed to use expect.
Do we know the reason for the inital change?

[NathanSWard]

Could we add unit tests to bind the HandleUntyped::typed behavior?

[alice-i-cecile]

Curious, I'm pretty sure handle used to return a Result/Option type and then it got changed to use expect.
Do we know the reason for the inital change?

Poking around, it looks like this got changed for 0.3, from https://docs.rs/bevy/0.2.0/bevy/prelude/struct.Handle.html to https://docs.rs/bevy/0.3.0/bevy/asset/struct.HandleUntyped.html#method.typed. Here's the line / commit to blame: c32e637#diff-cffa1459c07909ff31710f4d23192ae34a30938951b42076f162702f04c3f601L79

The PR description has no justification of this change; @cart did you have some Extremely Good Argument against making this return a Result/Option that we've overlooked? I suspect it was just overlooked :)

[cart]

No "extremely good argument". Just the argument that the implicit panic is more ergonomic. I'm down to change it, given how uncommon this scenario is.

[alice-i-cecile]

Closing this out, as I don't think it's relevant any more after #4794 :)