The default bug view has changed. See this FAQ.

runtime errors in wrapped JS are not made obvious

RESOLVED FIXED

Status

()

Core
XPConnect
P3
normal
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: John Bandhauer, Assigned: Mike McCabe)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+])

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
In calling wrapped JS objects xpconnect captures JS errors, builds an exception, 
and returns an xpcom error code. One can programatically get the most recent 
exception (with error report object) on the current thread using 
nsIXPConnect::GetPendingException(). It is not currrently printed. I can fix 
that.

We are going to need a global error reporter service. printf is not going to cut 
it in the long run. The DOM error reporter only works on DOM contexts. I assume 
that there is a bug about sending its output to a window. The JS loader and 
xpconnect should use an error reporter service to also get the data to a window 
console rather than the OS console that is not always going to be there.

I'm thinking about the short term here... In debug builds I can add code to 
printf errors and uncaught exceptions from calls to wrapped JS objects. This is 
not a production solution.
(Reporter)

Comment 1

17 years ago
I added the (debug build only) printf. We need to do better.
(Reporter)

Updated

17 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

17 years ago
Assignee: jband → mccabe
Status: ASSIGNED → NEW
(Reporter)

Comment 2

17 years ago
mccabe offered to add code to send these errors to his new console service.
(Assignee)

Comment 3

17 years ago
Created attachment 7812 [details] [diff] [review]
diffs to make xpcwrappedjsclass error reporter log to the console
(Assignee)

Comment 4

17 years ago
Marking 47013 as a dependency, and nominating nsbeta3.  Fix in hand.

This fix adds code to an XPConnect error reporter to register that error with
the JS Console.  So far as I can see, it's a clean addition.  Without this
patch, XUL/js developers won't see exceptions in JS code called from C++ unless
they're running debug builds.  Life would be better if this were not so.
Keywords: nsbeta3

Comment 5

17 years ago
This will be crucial for JS developers. Marking beta3+.
Whiteboard: [nsbeta3+]
(Assignee)

Comment 6

17 years ago
*** Bug 13187 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 7

17 years ago
Added 13187 as dup - possible extra issue to check is what JS Component errors
during registration time look like.
(Assignee)

Comment 8

17 years ago
I'm making another stab at this, logging the exception in a somewhat different
place, at John's suggestion.

I've also subsumed xpcJSErrorReport.cpp into nsScriptError.cpp.

Diff attached
Status: NEW → ASSIGNED
(Assignee)

Comment 9

17 years ago
Created attachment 12571 [details] [diff] [review]
log exceptions to the console and turn xpcJSErrorReport into nsScriptError.
(Assignee)

Comment 10

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

17 years ago
Ach, I think this is causing trouble.

I'm seeing an unfortunate behavior in the JavaScript console. Whenever the JS
console tries to QI (from JavaScript) one of the console messages to an
nsIScriptError, it might throw an exception (which is OK) but - due to the new
code, this exception logs another error, which ends up executing JS console
code, which tries to do a QI...

We need to short circuit this somewhere, or have a way to learn something more
about whether an exception will be uncaught.  Ideas requested.

Mike
(Reporter)

Comment 12

17 years ago
Yuk!

The JS console code could protect itself from re-entrance with a flag.

We could consider having the code in xpcwrappedjsclass only log a console 
message on JS errors and not on throws from the JS code. That would sort of 
suck.
I guess I'm missing something here -- are we really reporting caught-by-JS
exceptions as errors?  That would seem a little wrong -- there are lots of
correct programs that catch errors as part of interaction with their
environment, and they shouldn't be filling the error log.

If we're only logging uncaught exceptions, though, why not just have the JS
Console catch the possible exception from QI?
You need to log in before you can comment on or make changes to this bug.