- From: ben turner <bent.mozilla@gmail.com>
- Date: Sat, 7 Mar 2009 23:22:16 -0800
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. -Ben 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