debugging modules

[Jason Orendorff]

On Tue, Jun 24, 2014 at 1:11 PM, Guy Bedford <guybedford at gmail.com> 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