I generally don't find them useful, but instead annoying, and that they provide a lot of noise to filter out to find actual relevant errors. This is including the undefined property errors. It is a common JS style to pass around configuration/option objects that will be missing many properties that get accessed by functions they are passed to. My understanding is that part of this is special cased not to generate these messages, but in my experience it isn't close to enough.
At minimum, we should mark them all JSEXN_NONE in js.msg so that they don't appear as misleading ReferrenceError or whatever other kind of error. We also shouldn't call them "strict" errors, since they have nothing to do with strict mode. Additionally, whether these messages show up depends on how the JS is loaded. I haven't looked at the specifics in a while, but IIRC it depended upon whether you were using JSMs or Cu.evalInSandbox, etc. We have tests in devtools that fail if there are any errors in the console, and so changing the way we load JS sources with no other changes to the code, results in tests breaking for perfectly good code. It can be *very* frustrating. I'm like the idea of providing optional JS Hint style linting with these messages, but it isn't really optional right now, and even if you don't want these messages, they are still forced upon you. Personally, I'm A-OK with retiring these messages, but it seems at least some people do get value from them. Maybe this should be a flag? --enable-extra-js-warnings? A pref? Just not enabled by default, please... _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
