Importing modules that don't exist

[Andrea Giammarchi]

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 gmail.com> 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 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
>>>
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141121/d66c1833/attachment.html>