Remove javascript.builtins.Error.cause.displayed_in_console

[ddbeck]

Summary

javascript.builtins.Error.cause.displayed_in_console can never be incompatible because the contents of the console aren't inspectable.

Test results and supporting details

This is a weird thing. The appearance of the console is implementation-defined by specification. Arguably, the console output can look however a vendor wants it to look and it'd be standard behavior.

But unlike, say, the default stylesheet or a sensitive feature's permissions UI, the output of the console is not inspectable by a web page in any browser in any case. That is to say, there are no methods to read the console, only to write to it. You could never build a web application that depends on the output of the console. It's definitionally compatible because no browser exposes it to developer code or ordinary users (e.g., there's no way to trigger the appearance of the console).

That said, lots of stuff can be up to the implementer and still "incompatible" for developers, if they're too divergent. I get this. I think it's worth noting that Safari is alone in failing to print this information, so I've moved that information into the parent feature's notes.

Related issues

• Discovered in the course of ECMAScript discouraged/legacy feature web-platform-dx/web-features#2564. This is one of the first keys where I've wanted to not exist that wasn't already on the road to removal.

[Josh-Cena]

I think it's very important to note to developers which parts of the error are displayed, as that's basically the sole purpose of Error. In many of the applications I worked on, we had to hold off using cause for a while and bake the cause into our message exactly because it was not shown in the console—that would render it totally useless.

The way I think about it is this: BCD is documentation. It's just a part of content that's browser-specific, extracted to a more structured form—that's it. Automated checking is cool, but we can't take a set of automatically derived data and call that BCD, because its goal is to be developer-facing, and developers care about whether they can use a feature in a way it's intended to be used. If a part of the error doesn't show up in the developer tools, then it's by definition useless.

[ddbeck]

For additional context, over in web-features I'm trying to tag the last few remaining compat keys for JavaScript (see the description and discussion on web-platform-dx/web-features#2564 and this file in another PR). We've manually sorted and reviewed over 13,500 keys and this is the first one that I've contemplated omitting completely.

This key appears to be unique amongst all the JS keys (and perhaps all of BCD) in representing a UI distinction between browsers that is completely invisible and uninspectable within the document. It's also the only key I've encountered that hinges support on any developer tools whatsoever, which are known to vary widely between browsers.

If a part of the error doesn't show up in the developer tools, then it's by definition useless.

I don't think this is supported by the original proposal for cause. The example code given there does not contemplate the JS runtime printing cause information by default:

try {
  await doJob();
} catch (e) {
  console.log(e);
  console.log('Caused by', e.cause);
}
// Error: Upload job result failed
// Caused by TypeError: Failed to fetch

Searching for err.cause or e.cause in JS/TS files across GitHub reveals other interesting applications, such as conditionally handling errors depending on the cause and uploading cause information to an external logging service.

Moreover, if printing a cause by default were central to support for cause then that would imply Safari's support for the parent feature, javascript.builtins.Error.cause, ought to be marked as partial_implementation. I very much doubt that such a PR would get merged (and I would reject if it I were the reviewer).

BCD is documentation

Of course it is. There was a time I was the primary maintainer of this project. I'm not suggesting we ignore this difference. I think this information deserves to be in a note.

[Josh-Cena]

It is not partial implementation because the implementation follows the spec faithfully. It is a sub feature because developers are interested in knowing whether they can log an error and automatically see its cause. The proposal does not demonstrate dev tools because that would implicitly place a normative requirement on that behavior, but it can't; and if browsers ship cause without dev tools support, which they are allowed to, and users can't reproduce the behavior stated in the proposal, it's doing the user a disservice. We do the same in MDN actually: for example, in my SuppressedError demonstrations in mdn/content#38027, I manually walk the error structure because up till now Chrome dev tools does not show any subproperties of it. That doesn't mean that I as a reader won't be interested in knowing if it could show up by default, because if I'm making an error logging service I'd like to be as convenient and easy as possible without a lot of manual branching. The point being, many developers, including myself, would not be able to successfully use this feature without the dev tools support, so in fact, the support status of cause for me is when the subfeature gets implemented, and removing it is doing me a disservice.

The only other way I can think of is to have an implementation note for every initial implementation saying "not shown in the console", and a separate implementation without the note, but I fail to see how that would be different semantically.

[caugner]

Agree with OP, makes sense to me to no longer track this as a subfeature.

[Josh-Cena]

If "subfeature" strictly means "something dictated by the spec", then please add an implementation note to every initial release saying they don't display it in console, because that's the actual information deciding whether users can use it.