Error Handling: Why do we not return Results anymore?

[johannesvollmer]

Hi! First, thanks for this awesome webgpu implementation! It's awesome to finally have a truly cross-platform graphics API. <3

That being said, I have some questions about the API design of this crate. As a completely new user, I expected most methods to return errors, or futures, or a combination thereof. Instead, I found a global error handler, which must also be static and therefore cannot borrow local context. The global error handler reminded me of using C + OpenGL back in the day, which is an unpleasant memory haha.

What are the reasons for this design? Especially when compiling shaders, it would be very difficult to check the correctness of every shader in advance, and receiving a Result would be much less work for all the users of this crate. Considering that this crate is meant to be the idiomatic Rust wrapper, I would propose some kind of abstraction that allows us to return Results instead of calling an error handler.

I found #706 (and #638) but it seems like these changes a no longer with us.

[kvark]

Hi, and thank you for the kind words!

First, wgpu-rs doesn't return Error because the upstream Web API doesn't return errors for most things. See the error explainer. Thus, if we returned errors in wgpu-rs, we'd have this weird situation that you get errors when targeting native, but no errors when targeting the web. This would mean wgpu-rs API isn't well suited to target both of these uses.

Instead, aligning it with WebGPU specification allows users to have the same code running everywhere, and not 2 different ways to handle errors.

To clarify, user should be fully capable of writing an application that does NOT error. You shouldn't be trying to write run-time code dealing with errors, unless both conditions are satisfied:

1. the error is something you can't predict in advance. Like an out-of-memory error.
2. you actually want to handle it.

The (1) means that each method would return a Result. And the user code would just be littered with either "unwrap" or "?". The former is bad Rust, the latter doesn't show you where the error actually happened. Both require boilerplate.

So, instead, you handle only errors that you opt into. Unfortunately, wgpu-rs doesn't expose this right now, but it needs to.
I created #1735 to track this, even though it was well known and requested.

Also, to clarify, in WebGPU upstream (as well as wgpu-rs), if you are doing something wrong, like creating a texture with bad sizes, then it would still be created. It's completely valid to continue doing operations, like create other resources, submit command buffers, or even create resources based on this texture. This is how WebGPU upstream treats it.

[johannesvollmer]

Interesting. So, the whole thing is asynchronous, and most errors would not appear immediately, I see. I'm a little bit sad but I guess it's fine in the end. When error scopes come, it might get easier to compile runtime shaders.

Thanks for you the time you took for this detailed answer :)