Setting followup to jseng, since this is getting pretty off-topic for
here, and very on-topic for there.
On 1/31/11 10:01 PM, Zack Weinberg wrote:
That can't be right, because if I _catch_ the exception within
JavaScript, I get a broken down DOMException.
>
Maybe the lossage you remember happens at the point where we convert
uncaught JS exceptions to console messages? (Which I still can't find.)
http://hg.mozilla.org/mozilla-central/file/0a47be5cdd94/dom/base/nsJSEnvironment.cpp#l584
and
http://hg.mozilla.org/mozilla-central/file/0a47be5cdd94/dom/base/nsJSEnvironment.cpp#l448
And if you breakpoint in NS_ScriptErrorReporter, the incoming
JSErrorReport object has no filename and lineno set to 0, even though I
can confirm that catching the exception in JS has a useful lineNumber.
So something between when you catch the exception and when the JS engine
reports it to the embedding messes with it...
Looks like what happens is that XPConnect actually throws an object as
the exception. Then js_ReportUncaughtException calls
js_ReportErrorNumberVA which calls PopulateReportBlame which sees that
no script is on the stack (because this is happening after the JS is
done running) and does nothing. Then it calls js_ExpandErrorArguments
which sees js_GetErrorMessage as the callback, ends up with a
JSErrorFormatString with one argument, stringifies the exception, sticks
that into the report (but nothing else, so far), and reports _that_ to
the embedding.
Given that we have a nice exception object here with all sorts of
location info and jazz, could we somehow teach jseng to not forget that
when generating the JSErrorReport?
Is there a bug already? I can write a patch sometime this week.
Not yet. Want to file?
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
