Importing modules that don't exist

[Isiah Meadows]

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 wirfs-brock.com> wrote:

>
> On Nov 19, 2014, at 5:36 PM, Isiah Meadows <impinball at gmail.com> 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 wirfs-brock.com>
> 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
>> https://github.com/rwaldron/tc39-notes/blob/b1af70ec299e996a9f1e2e34746269fbbb835d7e/es6/2014-09/sept-25.md#loader-pipeline,
>> not sure where that ended up living.
>>
>> On Thu, Nov 13, 2014 at 7:37 AM, Isiah Meadows <impinball at gmail.com>
>> 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
>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-stati-semantics-parsemoduleandimports-realm-modulename.-visited 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141120/6f641ed3/attachment.html>