debugging modules

Guy Bedford guybedford at
Tue Jun 24 11:11:48 PDT 2014

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

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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list