Error messages produced by optional chaining operator

[thosrtanner]

I'm not entirely sure about his, but I think the ?. operator is producing messages it shouldn't.

For instance this example from MDN page

Code: Select all

function printCustomerCity(customer) {
  const customerCity = customer?.city ?? "Unknown city";
  console.log(customerCity);
}

printCustomerCity({
  name: "Carl",
  details: { age: 82 },
});

on firefox runs and prints "Unknown city" without any other output.

On Pale Moon, it prints "Unknown city" but it also produces a ReferenceError warning: "ReferenceError: reference to undefined property "city"[Learn More]"

Given the purpose of this operator is to behave in a defined way under those particular circumstances, this feels discouraging as even when I'm doing the right thing, I get warnings that I'm doing a wrong thing.

[FranklinDM]

I can't reproduce this. I've tried the example itself via the Scratchpad, Developer Tools Web Console, and using a test HTML file, and I'm not getting the reference error message that you've encountered. Are you using this in a different context (e.g. browser chrome code or JSM modules)?

[Moonchild]

Unable to reproduce as well. The MDN example properly prints "Paris" and "Unknown city" in succession without errors.

Can you please provide the full error message you get from the error console, i.e. including source data (module name, line:column, source snippet if provided)?

[thosrtanner]

I have 'JS warnings' switched on in the browser console.

This is the message I get (slightly simplified test)

Code: Select all

13:24:35.230 >> let x={}; console.log(x?.fred ?? "wibble")
13:24:35.291   wibble 
13:24:35.290 <- undefined
13:24:35.291 !  ReferenceError: reference to undefined property "fred"[Learn More]

Oddly, if I leave the ? out in the above, (using x.fred), I get no ReferenceError, which seems back to front to me.

[FranklinDM]

I still can't reproduce even with the given test.

By any chance, do you have the pref javascript.options.strict set to true? That's the only reason that I can think of which can make these warnings show up... IIRC we intentionally throw those as warnings for the optchain/nullish coalescing implementation in strict mode.

[thosrtanner]

Ah. Yes, I do.

Why'd you produce that warning when this is what those operators are designed to deal with?

Also in that case, why doesn't

Code: Select all

{ let x = {}; console.log(x.y ?? "wibble") }

produce a warning? I think it's more reasonable for that one to get a warning.

[Moonchild]

Why'd you produce that warning when this is what those operators are designed to deal with?

It's informational for devs more than anything else. The reason why it would make sense there is that there would be no indicator that a check is made against a null property otherwise.

x.y would just always evaluate to undefined.

x?.fred could have fred be either null or undefined and evaluate to undefined in both cases. If you expected null then the error thrown is invaluable for debugging your code. Also, the spec explicitly treats strict and non-strict differently for OptionalChain : ?. IdentifierName

Side note: forcing all scripts to be treated strict will cause compatibility issues on the web. I do not recommend it.

[thosrtanner]

my understanding of that option in about:config was that it'd produce the errors it would have produced in strict mode, but not actually change the processing. I can take if off as I was mainly using it to check the extension I was maintaining wasn't doing anything silly but I forgot to switch it off once everything was in modules.

However, could you explain how the spec says strict and non strict behaviour should be different for the ?. operator. Certainly the proposal has nothing to say on the subject (and the spec is hard to read!). Though having read MDN for about the 20th time, it looks like i shouldn't be using it at that point but at a later point.

Anyway, thanks for the help.

[Moonchild]

my understanding of that option in about:config was that it'd produce the errors it would have produced in strict mode, but not actually change the processing.

Ah seems you are right? I guess my understanding of the pref was wrong then.