debugging modules

Patrick Mueller pmuellr at
Tue Jun 24 16:36:06 PDT 2014

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

>  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> on behalf of Guy
> Bedford <guybedford at>
> *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 -
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list