debugging modules

[Patrick Mueller]

"This seems like a dev-tools problem" seems like semantic problem with the
design.  Some people write dev-tools with user-land code, and so those
people are screwed.
 On Jun 24, 2014 3:48 PM, "Domenic Denicola" <domenic at domenicdenicola.com>
wrote:

>  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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140624/201ca0ba/attachment.html>