Re: my summarized problem statement. I like @dmchurch 's one, but maybe a variant that doesn't reference console.log:
The
Errorclass doesn't have a built-in, standard way to add supplemental information to thrown errors, without subclassing or stuffing stringified data into its message.
Re: consensus/no-take-backsies: I agree, and maybe eventually I could fall in line, but I also suspect that simplicity of implementation, lack of edge cases, and precedent are important if we want to get this approved. Just adding this.detail = options.detail to the Error constructor is about as simple and non-controversial as it gets. Whereas the interpolation proposal has many tricky things to figure out:
- speccing out what happens to a static property in subclasses
- deciding how to format the detail parameters (in my
{foo: {bar: 1}}case, will we see[Object object]? - adding another two properties to Error, increasing likely clashes (
rawMessageandnew) - figuring out how to handle messages that just so happen to match the placeholder format (would
new Error('Product must have price > $0', {detail: [123]})be problematic? Maybe this objection is bogus?)
All of those are solvable, but each could be a sticking point gaining consensus. Then documenting how to use, because of this extra complexity, also becomes harder. (Also, I may have misunderstood, please let me know if I've got the wrong end of the stick with any of the above)
So, trying to put my committee member hat on, I think I would prefer the original, simpler, idea.
Having said that, I still like what you're proposing more than nothing, so I would lend it my (meaningless) vote if the original idea were rejected outright.
@ljharb since you're a delegate who has engaged with this, any thoughts? Did you find the reasons given why cause isn't suitable convincing? Any initial sense of whether new Error('thing failed', {detail: {code: 123}}) or Error.new`thing failed with code ${123}` seems more likely to get through?