gfx-rs
It is surprising / undocumented that some functions can panic due to validation errors
For example, I have observed panics in Device::create_shader_module and Device::create_render_pipeline. Neither function returns a Result or documents that it may panic. Functions should document under which conditions they panic and they usually do both in and outside of wgpu.
Following the stack trace I see that this likely related to UncapturedErrorHandler and Device::on_uncaptured_error. I see that the default error handler panics and I expect that a custom error handler could avoid the panic. If this is the intended way to prevent these panics then this should be documented.
Is there a particular reason why Device::create_shader_module() and Device::create_render_pipeline() default to panic rather than returning a Result?
For rapid iteration in development, I'd like to reload shaders on the fly, without recompiling and restarting the application. I can install a no-op handler via Device::on_uncaptured_error(), but I'm not sure how to to detect an invalid shader module and recover gracefully.
Is there a particular reason why Device::create_shader_module() and Device::create_render_pipeline() default to panic rather than returning a Result?
It's WebGPU spec compliance: The errors may happen asynchronously, therefore you have to install an error handler to handle them. Today, when you're on native wgpu, most errors happen synchronously but if you're targeting WebGPU actual that's rarely the case since browsers decouple the threads that your code runs in from the actual processing (what the WebGPU spec calls the Device timeline). Therefore, none of the wgpu exposed functions can return a result.
The default handler happens to panic. Every now and then there's a discussion whether that's a great or a horrible default. Not panicing and instead using logs means that a new user has to continuously check their logs for any incorrect api usage. Thinking currently is that it's too easy to miss. I believe for starters, all panics in the default log handler should point this issue out and direct users on how to install log handlers.
Oh, I see. Would it possible to modify the pipeline or the shader from the context of the error callback?
For example, a 3D engine might want to replace a broken fragment shader with a solid red color.
The wgpu::Error passed to the error handler does not include a reference to the pipeline or the shader, and since there's a single callback at the device level, there's no way to capture a reference when installing it.
You can use error scopes to capture errors from specific operations rather than all operations.
(Unfortunately, that's global state so it doesn't play well with using a device from multiple threads; #5375 tracks doing that better.)
