On Tue, Jun 24, 2014 at 12:53 PM, Guy Bedford <guybedf...@gmail.com> wrote:
> 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.
> });
>
>
Surely this case must call reject(). What circumstances would call
reject() if not the failure to import?
> 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.
>
I don't follow all of this but using your example from
es6-module-loaders/test for import('load/main') dependent on
'load/depError' which throws 'dep error', then we should be able to give an
error like
Module Evaluation Error: 'dep error' in
loads/deperror loaded by
loads/main
https://github.com/google/traceur-compiler/pull/1127
We can give line/col info with a bit of work in Traceur; it would be
trivial in a native implementation.
If the spec does not allow this, then we need to fix it.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
