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.
I added the (debug build only) printf. We need to do better.
mccabe offered to add code to send these errors to his new console service.
Created attachment 7812 [details] [diff] [review] diffs to make xpcwrappedjsclass error reporter log to the console
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.
This will be crucial for JS developers. Marking beta3+.
*** Bug 13187 has been marked as a duplicate of this bug. ***
Added 13187 as dup - possible extra issue to check is what JS Component errors during registration time look like.
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
Created attachment 12571 [details] [diff] [review] log exceptions to the console and turn xpcJSErrorReport into nsScriptError.
Fix checked in.
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?