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 <[email protected]> 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" <[email protected]> > wrote: > >> >> On Nov 19, 2014, at 5:36 PM, Isiah Meadows <[email protected]> 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" <[email protected]> >> 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 <[email protected]> >>> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
