device.create_shader_module panics instead of returning a Result for shader validation

[EriKWDev]

Is your feature request related to a problem? Please describe.
When creating shader modules using device.create_shader_module(..) (in my case with some wgsl shader source code), if the wgsl contains any errors, this function will panic.
I had to use a std::panic::catch_unwind for the first time to hackily mitigate this.

Describe the solution you'd like
After having gone into the source code at least a little bit it seems like there is a bunch of functions in the code base related to creating a shader module that all keeps track of a Result in case it didn't work. It would be very nice if the user-exposed create_shader_module would return a Result as well with potential validation issues or shader compilation issues.

Describe alternatives you've considered
Have a second function in utils or wherever called something like validate_shader so that I can validate a shader before sending it to wgpu causing a panic.

Additional context
Here, in direct.rs backend, an error is returned but the code winds up in default_error_handler and panics if it's not Ok(_). Could this not be returned to the user?

wgpu/wgpu/src/backend/direct.rs

Line 890 in 4d8a7ed

let (id, error) = wgc::gfx_select!(

Or at least exposed somehow.

Handling wgpu errors as fatal by default
thread 'assets_hot_reload' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_shader_module
      note: label = `wgsl`

Shader validation error:


    Entry point fs_main at Fragment is invalid
    The `return` value None does not match the function return value

', ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.16.0/src/backend/direct.rs:3019:5

[cwfitzgerald]

Hello, thanks for filing!

So this is an artifact of how we do error handling in wgpu. We want to allow users to run their code on top of WebGPU as well and WebGPU error handling is asynchronous. Because of this, in order to catch errors, you should use things like error scopes to be able to catch the errors on a specific command or set the uncaptured error handler if you want to deal with errors globally.

[cwfitzgerald]

Closing in favor of #3767 as this is a documentation issue.

[EriKWDev]

Had no idea! Thanks for the info :)

[nnmm]

In case other people find this issue, a related discussion is #2130