[whatwg/webidl] What's the idiomatic way to reject a promise with structured data? (Issue #1223)

Hello!

In WebGPU, the website provides shader source code as a string to the browser, for the browser to compile it. The compilation process is asynchronous, because it runs in the GPU Process. Of course, that shader source code string may be erroneous; if the compilation process fails, it's fairly natural to reject the promise. When we reject the promise, we'd like to provide structured data to the website that includes errors, warnings, message strings, line + column information, maybe things like the name of the function that had the error inside it, possibly error codes, etc.

This is oversimplified a lot, but an author's code would want to look somewhat vaguely like this:

```
compileShader(`
    struct Foo {
        /* members here, details not important */
    }
    fn bar(foo: Foo) {
        let baz = foo * 7; // Structs can't be multiplied by 7; this is a compile error
    }
`).then(function(compiledShader) {
    /* use the compiledShader */
}, function(compilerErrors) {
    console.log("There was an error inside the shader function " + compilerErrors.failedFunction);
});
```

However, https://www.w3.org/2001/tag/doc/promises-guide#reasons-should-be-errors says:

> Promise rejection reasons should always be instances of the JavaScript Error type, just like synchronously-thrown exceptions should always be instances of Error. This generally means using either one of the [built-in JavaScript error types](https://tc39.github.io/ecma262/#sec-error-objects), or using DOMException.

It's unclear how to attach structured data to an Error or a DOMException. Should we subclass `DOMException` as e.g. `RTCError` does? Or maybe we should attach a dictionary to the `cause` field of `Error`?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1223
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1223@github.com>