Importing modules that don't exist

[Isiah Meadows]

Easy enough:

```js
class ImportError extends Error {}
```

Now, patching module loaders would be a whole different beast. For Node,
luckily, it's as simple as this, if turning it into a runtime error is
permissible (very similar for other cases):

```js
// original
import foo from "./module.js";

// polyfill
var foo;
(function () {
    try {
        foo = require("./module.js").default;
    } catch (e) {
        var err = new ImportError();
        for (var i in Object.keys(e))
            err[i] = e[i];
        throw e;
    }
})();
```

For AMD, it would be similar to this:

```js
// original
import foo from "module";

// polyfill
define(["module"], function (foo) {
    foo = foo.default;
    // module body
}, function (e) {
    var err = new ImportError();
    for (var i in Object.keys(e))
        err[i] = e[i];
    throw e;
});

On Fri, Nov 21, 2014 at 5:49 AM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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
>>
>>
>


-- 
Isiah Meadows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141122/a231dbd3/attachment.html>