On Tue, Jun 24, 2014 at 1:11 PM, Guy Bedford <[email protected]> wrote: > If I load a module, where one of the dependencies of that module throws in > its immediate execution, the module I loaded will return successfully, while > the error will be thrown in the environment. [...]
I think it's just a mistake: a ReturnIfAbrupt is missing after EnsureEvaluated's recursive call to itself. That is, if something goes wrong during EnsureEvaluated, the error should be propagated. I filed a bug: https://bugs.ecmascript.org/show_bug.cgi?id=2996 Separately, as you say below, the failed module stays in the registry without being marked as failed. So a subsequent loader.get() can return it; later LinkSets can depend on it. (read on) > [...] There is no way to currently > see the tree that caused that module to be loaded in the first place. > [...] > My worry is that we get random errors in third party libraries, without > knowing how they even ended up being loaded. Oh, well, implementations should report the chain of imports that caused the throwing module to be loaded! The spec doesn't get into error messages generally. It's a quality-of-implementation thing. A note might be in order though. > The question then is what to do with these "failed" modules. I would > continue to store them in the module table as "failed", and anything that > imports from them as also "failed", and not to return as a successful import > but to rather invoke the import reject handler. > > I think this is important to simplify debugging. Sounds good. I agree. -j _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
