Check asset-path existence. Previously App just crashed if not

[Telzhaak]

AssetServer.load_untyped does not check the existence of a provided path, only whether the path itself has a valid format (e.g. the file-extension).
This leads to the application crashing if the filename is missspelled (Fire <-> Fira):

let wrong_path = std::path::Path::new("assets/fonts/FireSans-Bold.ttf");
let correct_path = std::path::Path::new("assets/fonts/FiraSans-Bold.ttf");

let maybe_font = asset_server.load(wrong_path);

ERROR bevy_asset::loader > Failed to load asset: Io(Os { code: 2, kind: NotFound, message: "Das System kann die angegebene Datei nicht finden." })
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', E:\Workspaces\Rust\Bevy\clone\crates\bevy_text\src\font_atlas_set.rs:53:42

This might be intended/desired behaviour, such that the typo is fixed right away.

---

My Issue with this:

1. The error-message does not provide information on which file could not be found, which makes it difficult to find the typo in case of a lot of assets.
2. Crashing is ungraceful and pretty demotivating for newcomers

My Fix:

1. Check existence and Return Error-Code with File-path (Much slower performance, so not feasible if the function is used in asset-streaming for large worlds?)
2. User can choose to internally handle error by e.g. having fall-back assets (could also be used to allow modding by having a default_asset/ and mod_asset/ folder?)

[cart]

I think I would prefer to not do file io when queuing up load tasks. Instead, can we add path information to the error message in ChannelAssetHandler by extending AssetLoadError::Io?

[Telzhaak]

You mean something like this?

The Original Io-Error is propagated, and the file-path is displayed in the error message.

ERROR bevy_asset::loader > Failed to load asset: Io(Custom { kind: NotFound, error: "assets/fonts/FireSans-Bold.ttf" })
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', E:\Workspaces\Rust\Bevy\clone\crates\bevy_text\src\font_atlas_set.rs:53:42

However, this still crashes the application.

ChannelAssetHandler::handle_request() is the only place the load_asset() function is used, which sends (apparently to font_atlas_set.rs in this case) an

AssetResult {
    handle: Handle::from(load_request.handle_id),
    result: load_asset(LoadRequest),
    path: load_request.path.clone(),
    version: load_request.version,
}

It look like the recipient of the message has to deal with the error (instead of using unwrap)?

[cart]

Yeah thats what I was thinking of.

And yeah the other issue is your talking about is "how should we handle asset load failures"? I think crashing forcing developers to solve problems in their code, so its a reasonable short term solution.

But that is probably something that deserves its own issue / discussion. Allowing developers to define error handling behavior is maybe the right approach here.

[DJMcNab]

@Telzhaak please respond in #2373 for the relicense to MIT/Apache 2.0. Thanks!