Bob Ippolito wrote:
> 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.
I just tried putting that check into getElement, and it causes problems.
There really has to be a separate function, because lots of code
expects nulls from getElement right now. But there is also lots of code
that can't handle a null return value. So a seperate getRequiredElement
or something; even if it does the same thing as getElement most of the
time (i.e., if you don't put MochiKit into some kind of debugging mode),
introducing the distinction makes the debugging at least possible.
Otherwise, at least for the particular kinds of cases I'm encountering,
the only way I can figure it out seems to be with alerts (ick), watching
the Javascript log to see between which alerts the error shows up.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
