"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" <[email protected]> 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 <[email protected]> on behalf of Guy > Bedford <[email protected]> > *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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
