Closed Bug 1179879 Opened 9 years ago Closed 8 years ago

Add "errorNumber" to nsIScriptError

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: fs, Unassigned)

References

Details

In bug 1179876, we would need an "errorNumber" property that can be used to have a link to an "MDN error reference" from errors thrown in the console.

The basic idea is written down in this etherpad: https://etherpad.mozilla.org/webconsole-mdn-error-msg and the discussion is happening here: https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/zUiTSyjIvOs

The idea would be to use links like:
https://developer.mozilla.org/docs/Web/JavaScript/Errors/JSMSG_BAD_RADIX

where "JSMSG_BAD_RADIX" is the "errorNumber" from our .msg files:

Web:
JS https://dxr.mozilla.org/mozilla-central/source/js/src/js.msg
DOM https://dxr.mozilla.org/mozilla-central/source/dom/base/domerr.msg
DOM bindings https://dxr.mozilla.org/mozilla-central/source/dom/bindings/Errors.msg 

Internal:
Ctypes https://dxr.mozilla.org/mozilla-central/source/js/src/ctypes/ctypes.msg
XPC https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/xpc.msg

It looks like JSErrorReport has an errorNumber property, not sure if this is the right one.

I can try to help implementing this, but I definitely would need some pointers.
Script error handling in Gecko is kind of a mess. It is changing, and will change more in the future. It's getting better, but I would advise in general against trying to change it or rely too much on it to accomplish your goals.

I think that this is not the right time to try to expose new pieces of information reliably through the error reporting infrastructure.

The information that is already web-exposed is fair-game. For DOM errors, we already expose various error names per-spec: https://heycam.github.io/webidl/#idl-DOMException-error-names

you see this by doing: |try { document.body.appendChild(document) } catch (e) { console.log(e.name); }|

The names in js.msg aren't web-exposed, never will be, and may very well change or disappear. So I don't think we should be building any MDN infrastructure around them. I don't think we want "JSMSG_NEED_DIET" to end up in the spec or in the URL of an MDN page.

As for the DOM Errors, I think that many of them are too general or vague to have all that much value as an MDN page. Some, like the indexedDB errors, could be very useful.

One cool thing would be to auto-generate a list of the locations that each error is supposed to be thrown per-spec (by crawling the relevant specs for references to them, like in [1].

[1] https://dom.spec.whatwg.org/#mutation-algorithms
Thank you, Bobby! Some thoughts:

(In reply to Bobby Holley (:bholley) from comment #1)
> Script error handling in Gecko is kind of a mess. It is changing, and will
> change more in the future. It's getting better, but I would advise in
> general against trying to change it or rely too much on it to accomplish
> your goals.

Is there a bug for these changes? I assume that we will always want to present an error string to web developers one way or another.

> I think that this is not the right time to try to expose new pieces of
> information reliably through the error reporting infrastructure.
> 
> The information that is already web-exposed is fair-game. For DOM errors, we
> already expose various error names per-spec:
> https://heycam.github.io/webidl/#idl-DOMException-error-names

This is fine, and we could provide help per error type. However, as you have noticed as well, this is too general and vague. Especially for ECMAScript errors, like TypeError or SyntaxError, we are missing the exact context. It is great that js.msg provides this context per error type. Very valuable collection in this file; great for Error-Driven-Documentation!

> The names in js.msg aren't web-exposed, never will be, and may very well
> change or disappear. So I don't think we should be building any MDN
> infrastructure around them. I don't think we want "JSMSG_NEED_DIET" to end
> up in the spec or in the URL of an MDN page.

The idea is to make a more fine-grained "errorNumber" available to DevTools code only. Not exposing it to the web directly. I don't know enough about nsIScriptError or XPConnect and if the proposed API addition would also make stuff available to the web – not intended. As far as MDN goes, it is really just about the URL, so that DevTools can link to a page that provides this info. NEED_DIET and other internal ones do not need to appear there at all. More about things like JSMSG_BAD_RADIX[1], JSMSG_BAD_ARROW_ARGS[2], JSMSG_BAD_OCTAL[3] and many many more. Currently, web developers copy the actual message into Google to learn at Stackoverflow what it means and how to fix. (I choose these 3 randomly and Stackoverflow had contents for all of them, found via Google in the first 5 results).
 
> As for the DOM Errors, I think that many of them are too general or vague to
> have all that much value as an MDN page. Some, like the indexedDB errors,
> could be very useful.
> 
> One cool thing would be to auto-generate a list of the locations that each
> error is supposed to be thrown per-spec (by crawling the relevant specs for
> references to them, like in [1].
> 
> [1] https://dom.spec.whatwg.org/#mutation-algorithms

If we would provide one page on MDN for the each of the DOM/JS error types that are web exposed, like TypeError and HierarchyError etc., without any additional level of granularity, we would end up with very long pages that contain various scenarios of when this type can be thrown. I guess DevTools could just link to that page, but without deep-link as there is no info about what exact error happened. A search and Stackoverflow answers, however, provide this context and is therefore much more relevant to web developers.

[1] http://stackoverflow.com/questions/16842534/rangeerror-radix-must-be-an-integer-at-least-2-and-no-greater-than-36
[2] http://stackoverflow.com/questions/20615839/syntaxerror-invalid-arrow-function-arguments-parentheses-around-the-arrow-func
[3] http://stackoverflow.com/questions/10333389/passing-a-value-through-to-a-function

(If we actually end up doing something like this and deal with the docs, one hope is that we and the MDN community could also give feedback about the actual usefulness of the messages and file bugs to improve them.)
(In reply to Florian Scholz [:fscholz] (MDN) from comment #2)
> Is there a bug for these changes?

Bug 981187 and its dependencies cover parts of it.

> I assume that we will always want to
> present an error string to web developers one way or another.

Sure - this is a question of the architecture that does that.

> This is fine, and we could provide help per error type. However, as you have
> noticed as well, this is too general and vague. Especially for ECMAScript
> errors, like TypeError or SyntaxError, we are missing the exact context. It
> is great that js.msg provides this context per error type. Very valuable
> collection in this file; great for Error-Driven-Documentation!
...
> The idea is to make a more fine-grained "errorNumber" available to DevTools
> code only. Not exposing it to the web directly.

Yes, but you're talking about encoding them into MDN URLs, right? I'm saying that these error identifiers are designed to be internal, and aren't stable enough to use externally.

> I don't know enough about
> nsIScriptError or XPConnect and if the proposed API addition would also make
> stuff available to the web – not intended. As far as MDN goes, it is really
> just about the URL, so that DevTools can link to a page that provides this
> info.

These messages aren't localized, right? With the existing tools, you can already write a regexp for the existing error messages (like /radix must be an integer at least/) that you want to write articles for, and then from devtools to the articles on MDN. You can even write tests to make sure that we update the regexps if the messages change.

Basically, I don't think the codes you see in js.msg have any more fidelity or stability than the messages themselves. You can already access the messages without platform changes, so I'd suggest just going with that.
Definitely neither error numbers nor error messages are any sort of interface at all, as opposed to internal-ish things.

It might be interesting to try to figure out some sort of way to associate an explanatory URL directly with every place where an exception is thrown.  It is *certainly* not the case that each error number, or error message, corresponds to exactly one particular mode of failure.  Errors are a property of the throwing location, not what the error says.  We'd have to add new API for this, of course, but we could always fault it into place on an as-needed basis depending on importance, or something.
(In reply to Bobby Holley (:bholley) from comment #3)
> Yes, but you're talking about encoding them into MDN URLs, right? I'm saying
> that these error identifiers are designed to be internal, and aren't stable
> enough to use externally.

True. I tried to come up with an identifier which would make sense. So, these internal identifiers were one idea. Need to think about alternatives then.

> These messages aren't localized, right? With the existing tools, you can
> already write a regexp for the existing error messages (like /radix must be
> an integer at least/) that you want to write articles for, and then from
> devtools to the articles on MDN. You can even write tests to make sure that
> we update the regexps if the messages change.
> 
> Basically, I don't think the codes you see in js.msg have any more fidelity
> or stability than the messages themselves. You can already access the
> messages without platform changes, so I'd suggest just going with that.

Yes, not localized as far as I can tell. Regexps sounded hacky to me at first sight, but you are right, we could even write tests here. Another benefit is also, that we could progress gradually. We could run an experiment with a handful of error regexp and have a chance to create good MDN pages for them, more regexps can follow as the MDN pages get written. The "white list" also allows us to not put any internal things like JSMSG_NEED_DIET etc. in there. More of a as-needed and most-confusing basis.


(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #4)
> Definitely neither error numbers nor error messages are any sort of
> interface at all, as opposed to internal-ish things.

Really wondering why this is not standardized. I mean as a web developer, it would be most helpful to get the same error messages for the same error in all browsers, right?

> It might be interesting to try to figure out some sort of way to associate
> an explanatory URL directly with every place where an exception is thrown. 
> It is *certainly* not the case that each error number, or error message,
> corresponds to exactly one particular mode of failure.  Errors are a
> property of the throwing location, not what the error says.  We'd have to
> add new API for this, of course, but we could always fault it into place on
> an as-needed basis depending on importance, or something.

This is true, but I think it is okay to have multiple cases of the same error message documented on the same MDN page. It would a nice idea for a v2 to take the throwing location into account and point to the exact section on that page then, for example. Need to explore the multiple failure modes more to see what is best and if that would work.

I really appreciate all your input on this topic! Please let me know if you have more thoughts.
I guess the original request (adding a errorNumber API) is WONTFIX here after all, though.
(In reply to Bobby Holley (:bholley) from comment #3)
> These messages aren't localized, right? With the existing tools, you can
> already write a regexp for the existing error messages (like /radix must be
> an integer at least/) that you want to write articles for, and then from
> devtools to the articles on MDN. You can even write tests to make sure that
> we update the regexps if the messages change.
> 
> Basically, I don't think the codes you see in js.msg have any more fidelity
> or stability than the messages themselves. You can already access the
> messages without platform changes, so I'd suggest just going with that.

Scanning https://dxr.mozilla.org/mozilla-central/source/js/src/js.msg I see a few duplicate messages - "invalid arguments" is used for JSMSG_TYPE_ERR_BAD_ARGS, JSMSG_TYPEDOBJECT_BAD_ARGS, JSMSG_TYPED_ARRAY_BAD_ARGS.  Looks like "invalid object argument" and "invalid or out-of-range index" are also used 3 times.

I'm not sure if there is any value to MDN providing different pages for these different errors, but it's something to keep in mind with using a regexp as the key instead of the code.  But since it sounds like those messages aren't required to be stable, maybe we could just change any message to be unique if it has an MDN page associated with them.
So, there have been more thoughts on the regexp approach and general comments. I recommend reading (and also commenting) this thread: https://groups.google.com/d/msg/mozilla.dev.developer-tools/zUiTSyjIvOs/

Regexps seem to be a pretty big workaround to avoid the platform just exposing the JSMSG_BAD_RADIX, etc. names to chrome-only code. And even with regexps or with any other approach, we would need an identifier for the urls, which is very similar or the same as the one we have already. Example by :hallvors:

if re.search('^.* is not defined$', message):
    err_id = 'JSMSG_NOT_DEFINED'

"The "symbolic names" for errors are good matches as unique short identifiers, and even if they sometimes change we probably need documentation updates anyway when that happens."


(In reply to Brian Grinstead [:bgrins] from comment #6)
> I'm not sure if there is any value to MDN providing different pages for
> these different errors, but it's something to keep in mind with using a
> regexp as the key instead of the code.  But since it sounds like those
> messages aren't required to be stable, maybe we could just change any
> message to be unique if it has an MDN page associated with them.

MDN is also able to create redirect pages in the wiki, so if we create the pages JSMSG_TYPE_ERR_BAD_ARGS, JSMSG_TYPEDOBJECT_BAD_ARGS, and JSMSG_TYPED_ARRAY_BAD_ARGS, the last two ones could just redirect to the first one, for example.
(In reply to Florian Scholz [:fscholz] (back on Aug 24) from comment #7)
> Regexps seem to be a pretty big workaround to avoid the platform just
> exposing the JSMSG_BAD_RADIX, etc. names to chrome-only code.

"just". As explained in comment 1, Adding platform support for this is far from trivial. Whatever identifier we try to expose here is going to get swallowed in a bunch of places, and then we'll need to fix them.

Basically, the error reporting infrastructure needs 2-3 months of dedicated time from an experienced platform hacker before it is in a state where we can add features to it. Those resources aren't there right now, which is why I'm suggesting that you work around it.

> And even with
> regexps or with any other approach, we would need an identifier for the
> urls, which is very similar or the same as the one we have already. Example
> by :hallvors:
> 
> if re.search('^.* is not defined$', message):
>     err_id = 'JSMSG_NOT_DEFINED'
> 
> "The "symbolic names" for errors are good matches as unique short
> identifiers, and even if they sometimes change we probably need
> documentation updates anyway when that happens."

You are free to reuse those names, such that we could eventually eliminate the regexp hackery when the error reporting infrastructure is solid enough to expose those names reliably. I'm just saying that it's impractical to rely on the platform to pass them to you at this juncture.
So personally I think using those internal IDs in URLs is fine but perhaps '../errors/Foo-is-not-defined' would be better search engine fodder?
> Really wondering why this is not standardized. I mean as a web developer, it would be
> most helpful to get the same error messages for the same error in all browsers, right?

In practice, what this would mean is that you'd get the lowest-common-denominator least-informative errors possible in all browsers.  The lack of standardization here means browsers can provide more information if it's easy for them (and often do; some of our error messages are much better than Chrome's and vice versa).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Pushed by mphillips@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/48034e1448f2
Add more doc links to console errors; r=mrrrgn
Wrong bug# in that changeset?  What's the right bug#?
Flags: needinfo?(mphillips)
(In reply to Boris Zbarsky [:bz] from comment #12)
> Wrong bug# in that changeset?  What's the right bug#?

Oy, looks like it should have been bug 1179876
Flags: needinfo?(mphillips)
You need to log in before you can comment on or make changes to this bug.