Last Comment Bug 24688 - runtime errors in wrapped JS are not made obvious
: runtime errors in wrapped JS are not made obvious
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: x86 All
P3 normal (vote)
: ---
Assigned To: Mike McCabe
: Robert Ginda
: Andrew Overholt [:overholt]
: 13187 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2000-01-21 12:49 PST by John Bandhauer
Modified: 2000-08-13 15:43 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

diffs to make xpcwrappedjsclass error reporter log to the console (1.86 KB, patch)
2000-04-21 03:17 PDT, Mike McCabe
no flags Details | Diff | Splinter Review
log exceptions to the console and turn xpcJSErrorReport into nsScriptError. (18.22 KB, patch)
2000-08-08 19:27 PDT, Mike McCabe
no flags Details | Diff | Splinter Review

Description User image John Bandhauer 2000-01-21 12:49:32 PST
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 

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.
Comment 1 User image John Bandhauer 2000-01-26 03:23:47 PST
I added the (debug build only) printf. We need to do better.
Comment 2 User image John Bandhauer 2000-04-20 17:23:51 PDT
mccabe offered to add code to send these errors to his new console service.
Comment 3 User image Mike McCabe 2000-04-21 03:17:01 PDT
Created attachment 7812 [details] [diff] [review]
diffs to make xpcwrappedjsclass error reporter log to the console
Comment 4 User image Mike McCabe 2000-08-02 14:08:13 PDT
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.
Comment 5 User image Patrick C. Beard 2000-08-02 16:38:06 PDT
This will be crucial for JS developers. Marking beta3+.
Comment 6 User image Mike McCabe 2000-08-07 17:26:26 PDT
*** Bug 13187 has been marked as a duplicate of this bug. ***
Comment 7 User image Mike McCabe 2000-08-07 17:27:19 PDT
Added 13187 as dup - possible extra issue to check is what JS Component errors
during registration time look like.
Comment 8 User image Mike McCabe 2000-08-08 19:24:10 PDT
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
Comment 9 User image Mike McCabe 2000-08-08 19:27:44 PDT
Created attachment 12571 [details] [diff] [review]
log exceptions to the console and turn xpcJSErrorReport into nsScriptError.
Comment 10 User image Mike McCabe 2000-08-09 16:01:43 PDT
Fix checked in.
Comment 11 User image Mike McCabe 2000-08-11 17:54:15 PDT
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.

Comment 12 User image John Bandhauer 2000-08-11 18:29:30 PDT

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 
Comment 13 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-08-13 15:43:00 PDT
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?

Note You need to log in before you can comment on or make changes to this bug.