[Webkit-unassigned] [Bug 8519] WebCore doesn't fire window.onerror event when uncaught JavaScript exceptions are thrown

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=8519





--- Comment #30 from Garrett Smith <dhtmlkitchen at gmail.com>  2009-09-11 16:40:06 PDT ---
On Sun, Aug 16, 2009 at 2:15 PM, <bugzilla-daemon at webkit.org> wrote:
> https://bugs.webkit.org/show_bug.cgi?id=8519
>
>
> Erik Kay <erikkay at chromium.org> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |erikkay at chromium.org
>
>
>
>
> --- Comment #28 from Erik Kay <erikkay at chromium.org>  2009-08-16 14:15:45 PDT ---
> When you say "it can't be a compat concern", you're only looking at it from one
> angle of compat.  I agree that it's unlikely that websites will break if this
> callback doesn't exist.  However, the existence of the feature allows websites
> to detect and fix other webkit compat issues more quickly.  For example, the
> gmail 

GMail is not such a good case because the code is not valid syntax for an
ECMAScript program.

case sited previously means that any unhandled exceptions can be logged
> to a server where they can be detected, quantified, analyzed, etc.  Without
> this, it's quite possible that the site owners won't realize that their site is
> broken in webkit browsers as quickly as other browsers (or perhaps at all if
> the effect of the error is subtle).
>
> Incidentally, I ran into this myself trying to build some unit tests for chrome
> extensions and not wanting to have to fill the code with zillions of try/catch
> blocks.  The net effect for me is a lot more effort and a longer debug cycle
> (since unhandled exceptions wind up leading to timeouts in the test rather than
> hard errors).
>
Wrapping everything in a try/catch is something that beginners will tend to do.

If the unhandled exception was thrown from a setTimeout, catch it using an
asynchronous testing approach. 

testXXX : function() {
   function myCallback() {
     fired = true;
   }
   someObj.sendMessage(myCallback);

   currentTest.wait(function(){ 
    Assert.isTrue(fired, "callback didn't fire");
   }, 20);
}

And you can see global the try-catch in GMail. Comment 13 mentions using
|window.onerror| instead:

Here we can see what looks like a function declaration inside of a block; 

try{function e(b){throw b;}var
h=true,j=null,k=false,aa=encodeURIComponent,aaa=JS_OBFUSCATED,ba=Object,l=Error,ca=parseInt,da=parseFloat,baa=Function,ea=GLOBALS,fa=decodeURIComponent,ga=

It would be reasonable to expect a SyntaxError from such syntactically invalid
code, except for the fact that that is not what browsers do, and that falls
into the realm of syntax extensions and error handling and this depends on the
implementation.

A window.onerror event callback mechanism would be useful for a testing
framework. I can see how window.onerror seems attractive for reasons mentioned
in comment #13, however such motivation is both driven by and serves to
encourage poor programming practices (such as those used in GMail) and should
not be used in production (as GMail).

So, if a window.onerror is desirable, the reason for it is not given in comment
13.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.