On Dec 2, 2005, at 3:22 PM, Ian Bicking wrote:
Ian Bicking wrote:
I've been getting lots of exceptions like these in Firefox:
Error: uncaught exception: [Exception... "Component returned failure
code: 0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)
[nsIXPCComponents.lookupMethod]" nsresult: "0x80570009
(NS_ERROR_XPC_BAD_CONVERT_JS)" location: "JS frame ::
chrome://global/content/XPCNativeWrapper.js :: anonymous :: line 91"
data: no]
I meant to try to reproduce in a more isolated way, but got
distracted. Anyway, to follow up -- I've been encountering these
more lately, and they seem to always come down to bad DOM calls.
Like if I do:
MochiKit.DOM.addElementClass('foo')
Which you might notice is missing an argument. I do that a lot; I
guess because MochiKit.DOM is like DOM, except for the first
argument (method vs. function). Anyway, this seems to get passed
all the way into Firefox where it produces this peculiar error,
with seemingly all the context lost so even Venkman doesn't show
anything useful. Pain in the butt.
One possible resolution would be more tests in MochiKit for null.
E.g., if addElementClass tested if obj was null and threw an error
immediately. Or, since in most cases it's the result of a
getElement() call that returns null, maybe another function like
getElement that will throw an error when an element isn't found, or
when it is passed null. Of course, this isn't great, because the
failure will be centralized in one function with no indication of
where in *my* code I messed up... but at least Venkman should work
better in that situation. Not that I use Venkman much, but maybe I
should. I'm guessing Firefox 1.5 didn't add tracebacks to the
console, too bad... I'm not sure I have the willpower to really
figure Venkman out at this point. I have to check out Console2
though: http://forums.mozillazine.org/viewtopic.php?t=318102
I've never had too much trouble tracking these sorts of problems down
in Firefox. Even doing a try{}catch(e){} will give you an exception
object that has a traceback in it, so it doesn't really take long to
figure out what the code path was even without Venkman's help.
I am kind of wary of maintaining all that extra preamble code all
over the place when size and speed are important design parameters.
In correct code, all that stuff goes away.
I guess I could make it possible to instrument
MochiKit.DOM.getElement with a version that throws on bad input, and
you could track it from there... sort of like in Objective-C where
you can set a compiler flag that raises exceptions if you send
messages to nil.
-bob
