Importing modules that don't exist

Andrea Giammarchi andrea.giammarchi at
Fri Nov 21 02:49:55 PST 2014

a native ImportError seems to me the best option and it's also easy to
polyfill in a meaningful way with all current module loaders used already
out there.

just my 2 cents

On Fri, Nov 21, 2014 at 3:10 AM, Isiah Meadows <impinball at> wrote:

> Should we, then, throw a SyntaxError, a new Error subclass created for the
> purpose, since we don't have a dedicated Error class for it yet (e.g.
> ImportError), or just a generic Error?
> My thoughts about each option:
> 1. SyntaxError isn't relevant, since it's about a file that doesn't exist,
> not an actual syntactic problem with the code.
> 2. A new Error subclass can easily be made descriptive, but it would add
> another variable into the global namespace, and we all know the risks
> associated with that.
> 3. A generic Error wouldn't tell us anything unless we parse the console
> output, which is inherently not portable. The only way this will become
> significant is in System.loader, where failures are probably very
> important. That could become quickly meaningful on the Web, where scripts
> are run as ScriptBody, without the module semantics.
> Why I suggested throwing a static ReferenceError is because module
> specifiers *are* references, specifically references to files. Static
> errors are almost never caught, since the only place to catch them is in an
> eval or equivalent.
> Looking back, it may be best for implementors to have to figure out what
> to do with missing modules.
> On Nov 20, 2014 12:49 PM, "Allen Wirfs-Brock" <allen at>
> wrote:
>> On Nov 19, 2014, at 5:36 PM, Isiah Meadows <impinball at> wrote:
>> Okay. Should a ReferenceError be the appropriate one in this case?
>> I don’t think so, ReferenceError is normally used for when a runtime
>> IdentiferReferece (or derived value) can not be resolved.  Module
>> references are not really the same thing.  There are really more related to
>> the syntactic composition of the program so SyntaxError might be
>> appropiate. In fact these errors are detected in ParseModulesAndImports
>> which is a “static semantics” routine (i.e., it is about the static
>> semantics rather than the runtime semantics of a program).
>> What the algorithm actually says is: “If *src* is an abrupt completion
>> or any other implemention defined error indication, then…” after trying to
>> retrieve the source.  The reason it says “or any other … error indication”
>> as this error might be detected before any ES code actually runs.  For
>> example a command line ES engine might parse and link all of the modules
>> listed on the command line and report missing module  warnings before
>> executing any ES code.
>> Allen
>> On Nov 13, 2014 1:29 PM, "Allen Wirfs-Brock" <allen at>
>> wrote:
>>> On Nov 13, 2014, at 5:16 AM, Calvin Metcalf wrote:
>>> It should throw a static error, the loader is where this is specified I
>>> believe, but it looks like the loader was pulled out into it's own spec
>>> not sure where that ended up living.
>>> On Thu, Nov 13, 2014 at 7:37 AM, Isiah Meadows <impinball at>
>>> wrote:
>>>> What happens if a module isn't able to be found? Is that implementation
>>>> defined, or have I missed it in the spec?
>>> See
>>> steps
>>> 10 and 11.  If the "host" can not provide the source for a module (as would
>>> be the case if the module name is invalid or the module is missing)
>>> HostGetSource is supposed to throw an throw an exception.  However, the
>>> actual exception that is thrown in that case is not currently specified.
>>> For an invalid name in an import declaration, this would occur during a
>>> recursive call to ParseModu8leAndImports, stoep 17.d
>>> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list