If it is a tools problem, it becomes a much more complex problem.
Firstly note that the promise isn't rejecting, it is resolving correctly.
That is if I have a module X:
X.js
throw "this module throws";
Then:
System.import('X').then(function(m) {
// this returns correctly, with m defined.
});
So the only information we have is the environment exception that something
went wrong executing module X. We have no information of what dependency
chain caused this.
If we want to inspect the dependency chain, there is nothing to inspect,
since we don't even know what loads might have caused it in the first place.
So there is no way for a debugger to tell the user anything useful apart
from inspecting the entire dependency tree. The evaluation chain that was
an explicit set of modules for ensureEvaluated, is no longer available for
useful debugging.
On 24 June 2014 12:47, Domenic Denicola <dome...@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-boun...@mozilla.org> on behalf of Guy
> Bedford <guybedf...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
