On 2011-01-31 8:41 AM, Boris Zbarsky wrote:
On 1/31/11 11:35 AM, Mike Shaver wrote:
On Mon, Jan 31, 2011 at 6:16 AM, Boris Zbarsky<[email protected]> wrote:
Apart from the "nsresult" bit, the hex code for the nsresult, and the
"NS_ERROR" prefix, is there other jargon?
The extra [Exception...] and code 12, at least.
"12" is the per-spec value of DOM_SYNTAX_ERR, which is the exception
being thrown (see the DOMException interface in DOM Core). It's not
xpcom anything.
>
In general we also don't say which method is being called incorrectly,
IIRC.
Yes, in this case. I'm not saying this exception message doesn't have
major issues, which we should fix! It's just that most of those issues
have nothing to do with "xpcom".
I suppose I should have said "internal jargon" rather than "XPCOM jargon".
My idea of a makes-sense-to-web-developers version of this message would be
Uncaught exception, thrown by matchesSelector:
DOM_SYNTAX_ERR (An invalid or illegal string was specified)
File: file:///tmp/test.html Line: 14
with the file and line properly hooked into the error console's location
machinery.
Hmm. We have bugs on that, for what it's worth; it's not that easy
last I checked.
Seems like a last-error singleton would work, in concert with our
single-threadedness?
I think the hard part was finding all the fiddly xpconnect bits that
needed fixing (well, and the fact that exception throwing can nest and
such).
As I mentioned a bit upthread, I looked for the code that does the
nsresult-to-JS-exception conversion and didn't find it. Well, I found
things that *might* be it, but they were doing all sorts of complicated
stuff that didn't make sense to me and so I wasn't sure.
It seems like that code is already doing almost what it needs to,
though. For the exception we've been kicking around, it fabricates a
DOMException object with separate properties for the location, line
number, error code name, and error message. It ought to also record the
name of the function that threw the error; I could believe that that's a
pain, though.
The real problem as I see it is that the error console (and the "web
console") don't break the exception down appropriately; they seem to be
just calling toString on the exception object and dumping the result
into the log window. *That* should be fixable without mucking with
XPConnect. I would like to think so anyway.
zw
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
