EDIT: moved comment here: #197 (comment) because it makes more sense on that PR

Consider this: OpenGL errors are categorized, and no more than one error of any particular type is reported at a time. Out-of-memory is essentially the only one an app would like to try to recover from. Does it seem a good idea to allow that recovery to be robust - no matter what kind of GPU object was allocated that triggered the OOM?

Thank you @kainino0x for doing this work! It is much easier to digest with 3 separate PRs.
Here are my 2 cents below.

TLDR;

• Rename gpulogentry to validationerror for clarity.
• Use an EventHandler for GPUDevice
• Remove object and use debug label in newly renamed message attribute.

partial interface GPUDevice : EventTarget {
  attribute EventHandler onvalidationerror;
};

onvalidationerror is an EventHandler which is called whenever a validation error occurs in the API (including operations on "invalid" WebGPU objects).

[
    Constructor(DOMString type, GPUValidationErrorEventInit gpuValidationErrorEventInitDict),
    Exposed=Window
]
interface GPUValidationErrorEvent : Event {
  readonly attribute DOMString message;
};

dictionary GPUValidationErrorEventInit : EventInit {
  required DOMString message;
};

Fire an event named "validationerror" at GPUDevice using GPUValidationErrorEvent with its message attribute initialized to the validation error message. It should include the debug label of the object if possible.

Moreover, in your other PRs, you've include some Javascript examples. And I really liked it. Maybe doing the same here could be nice as well.

const gpuAdapter = await gpu.requestAdapter({ /* options */ });
const gpuDevice = await gpuAdapter.requestDevice({ /* options */ });

gpuDevice.addEventListener('validationerror', function(event) {
  console.log(event.message);
  // TODO: Push logs to remote server for telemetry.
});

Applied your changes, thank you for the input! Not 100% certain that all log entries would be validation errors, but did that rename for now.

Can you check the wording for "fires on the main thread event loop"? Not sure how to word it properly.

@beaufortfrancois I have glanced at the Reporting API, but I haven't dug into it enough to understand whether it relates to the kind of reporting we need. Do you know whether we should try to integrate (or merge) this stuff with it?

Reading a little further it seems like:

• It could be good to surface these errors through it (but it would probably be ideal if we can surface only one error per app error?)
• Not enough adoption to merge, but we can have our error stream feed into it later on

Discussed at the 11 Feb 2019 WebGPU Meeting

Merged at the meeting, any further comments can be addressed later