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" <al...@wirfs-brock.com> wrote: > > On Nov 19, 2014, at 5:36 PM, Isiah Meadows <impinb...@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" <al...@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 <impinb...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
