W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Script loading and execution order for importScripts

From: ben turner <bent.mozilla@gmail.com>
Date: Sat, 7 Mar 2009 23:22:16 -0800
Message-ID: <21b1517c0903072322q64dfa56dm206be23ec8dd92be@mail.gmail.com>
Just to clarify, if two scripts fail to load or compile then Mozilla
always throws the error encountered by the first of the failed
scripts. So, if I have a worker that does this:

  importScripts("1.js", "2.js", "3.js");

and "1.js" fails to load and "3.js" fails to compile then we report
the failed load of "1.js". There is no race here.


On Sat, Mar 7, 2009 at 9:04 PM, Oliver Hunt <oliver at apple.com> wrote:
> Why do you think it's important not to have side effects for syntax
> errors but don't think it's important to not have side effects for
> run-time errors? Given that we simply can't fix the latter, I don't
> see any advantage to users to attempt to fix the former.
> I really don't think optimizing for the case when something has gone
> wrong is the way to go. That is an extremely rare case in a deployed
> application, and so optimizing for performance feels much more
> important to users.
> Also considering how applications are likely to handle these errors,
> I.e. full abort and tell user that an unrecoverable error has
> occurred, it doesn't really matter if there have been side effects or
> not.
> The primary situation i'm imagining could happen is one script starts
> manipulating a client side database onload (maybe ?a?conscious?decision to
> do db work while waiting for io), then the next script fails to load due to
> (say) a network failure, then your left with side effects they may not be
> reasonably recoverable. ?Arguably this design should be considered flawed
> anyway, but people tend to test under ideal conditions more often than not.
> ?The counter argument is that protecting developers from their own
> foolishness is not a goal.
> / Jonas
> --Oliver
Received on Saturday, 7 March 2009 23:22:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:10 UTC