We could remove some of the mystery of debugging by having a top-level catch for any javascript error in debug mode. (Should not install this if we detect that Firebug or some similarly powerful debugger is already there.) Relevant email thread:

From: Jim Grandy <jgrandy@openlaszlo.org>
Subject: Re: OL4 DHTML, null pointers, exceptions
Date: Mon, 26 Mar 2007 17:39:43 -0700

This just occurred to me, but what about putting try/catch around all
even dispatches, with a (debug-only) warning printed in the catch
block? That would at least keep the program executing, and alert the
programmer to an issue that needs to be addressed.

Looking at it from the perspective of the OL developer porting from
3.x to DHTML, this is a major blocker -- they try to run the app, and
the loading bar just spins without any feedback. Anything we can do
to get the app up and stumbling, however poorly, would be a big deal.

jim

On Mar 26, 2007, at 5:03 PM, P T Withington wrote:

> Well, the compiler does insert try/catch around all ref's that it
> can't prove are defined, but only in debug mode, because it slows
> things waaay down. (You have to put the try/catch as tightly as
> possible around the reference expression if you want any hope of
> continuing. And further, since JS blocks can't return a value, I
> actually have to put the try/catch in a closure, turning the
> variable reference into a function call.)
>
> I only do this for variable refs, because trying to validate
> property refs made things unacceptably slow, and hence calls to
> undefined methods also are unprotected.
>
> So, the answer is yes, we could do this, and we do to some extent,
> but only in debug mode.
>
> If you test your code in debug mode in swf and if you compile with
> warnings on and eliminate all warnings you will get a long way to
> not having runtime errors, but in a dynamic language, the
> programmer can always outwit the compiler (e.g., Adam's favorite
> trick:
>
> foo['on' + bar].sendEvent();
>
> [Ok, this is actually protected by hand, but you get the idea])
>
> Now, if this were Lisp, where we had CONDITION-BIND, we could do
> this with one binding and not slow things down at all.
>
> If someone else has a brilliant idea, I am open to it, but that was
> the best I could think of.
>
> On 2007-03-26, at 19:20 EDT, Jim Grandy wrote:
>
>> This should be a FAQ entry (if we had a faq) or something in the
>> dguide. He's wondering why we have to warn folks about null
>> property references in DHTML.
>>
>> Begin forwarded message:
>>
>>> From: David Temkin <temkin@laszlosystems.com>
>>> Date: March 26, 2007 3:20:05 PM PDT
>>> To: Jim Grandy <jgrandy@openlaszlo.org>
>>> Subject: OL4 DHTML, null pointers, exceptions
>>>
>>> Probably a stupid question. I'll ask anyway:
>>>
>>> Does browser JS support exceptions? If so, can we wrap our code
>>> in a "try...catch" so that execution doesn't stop when a null
>>> access is attempted?
>>>
>>>
>>
>