Clarify popErrorScope() rejects with OperationError if the device is lost - #433
Conversation
There was a problem hiding this comment.
Makes sense to me, only concern is it's not really technically aborted if the device is already lost. I also don't think the error types really matter to anyone unless there are multiple error types from a single call, so maybe OperationError is sufficient.
|
Is the idea that any device calls would result in How is "DeviceLost" conceptually different, from the caller point of view, from an object that is just internally invalid (i.e. a command encoder that just tried to bind and invalid binding, thus it's invalid itself)? |
|
Most operations [EDIT: don't] surface an error, except via popErrorScope or unhandlederror. So this case is special relative to most operations. Note that this rejects, not throws an exception. If a device is lost, even if it's known client-side to be lost, we would expose it by every operation producing an error into the error scope stack, which may bubble out to unhandlederror. I agree that doing operations while a device is lost should behave approximately the same as doing operations on an object that's invalid. |
|
F2F resolution: We need to ask someone who knows what AbortError typically means in other specs vs OperationError. |
|
@domenic or @foolip may help. |
|
Exception types aren't used very consistently and it also doesn't matter too much beyond being able to distinguish failure modes for the same API call that one would handle differently. |
|
That being said, it sounds like this exception would be thrown at any time after the device has been lost, and isn't itself signaling that the device was lost, so InvalidStateError might also be a candidate. |
|
Thanks for the feedback @foolip. Since the rest of the API uses OperationError for most things and there isn't a need (yet) to distinguish between error types for this call, it's seems best if we leave it as OperationError. |
|
Sounds like we wanted to update this to OperationError. Can you take care of that @austinEng? |
Co-Authored-By: Justin Fan <jussnf@gmail.com>
Co-Authored-By: Justin Fan <jussnf@gmail.com>
The popErrorScope() was changed to reject with an OperationError if the GPUDevice is lost[1]. So, this patch matches up with the spec. Also, although the spec doesn't mention it yet, we should make it throw an OperationError for all cases where the device is lost. [1] gpuweb/gpuweb#433 Bug: 852089 Change-Id: I3a80b5e741e1ea831fd92aa2eb3dcdafd6bc740e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1898891 Reviewed-by: Austin Eng <enga@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Corentin Wallez <cwallez@chromium.org> Cr-Commit-Position: refs/heads/master@{#712587}
* Organize more and add more test stubs * address comments, edit a tiny bit more
According to MDN, AbortError means "The operation was aborted."
When the device is lost, any attempt to
popErrorScopeis aborted and cannot complete because the device is gone. This is the same DOMException that the:Preview | Diff