debugging modules

[Domenic Denicola]

This seems like a dev-tools problem, and/or an issue of how informative the promise rejection's `.message` should be. I don't see anything we should be doing at the language level.


________________________________
From: es-discuss <es-discuss-bounces at mozilla.org> on behalf of Guy Bedford <guybedford at gmail.com>
Sent: Tuesday, June 24, 2014 14:11
To: es-discuss
Subject: debugging modules

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. 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.

I understand at a theoretical level that because of circular references, there is no single path for any given module execution, so that this doesn't make any sense.

At the same time, I loaded X, and got an error in Y, so I need some way to inspect the dependency relations between X and Y to know how it got loaded. If we consider this as all possible relations, things get very complex.

The thing is though, there is a single execution thread, which can throw back to the importing module. And I think that is more sensible, as that is the information that is useful to the user.

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.

See related issue - https://bugs.ecmascript.org/show_bug.cgi?id=2993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140624/58c27870/attachment.html>