ModuleDeclarationInstantiation behaviour after failure
allen at wirfs-brock.com
Wed Jul 20 17:36:50 UTC 2016
> On Jul 20, 2016, at 8:47 AM, Jon Coppeard <jcoppeard at mozilla.com> wrote:
> On 18/07/2016 19:04, Allen Wirfs-Brock wrote:
>> The intent is that after the “host” has fetched a module (and its
>> dependencies) it enqueue a TopLevelModuleEvaluationJob.
> OK, so calling EnqueueJob with a TopLevelModuleEvaluationJob is how this
> is supposed to happen.
> That doesn't give an indication of whether the job succeeded though
> (except for the fact that it would call HostReportErrors some time
> later). Is it possible to to find out whether this was successful
> without relying on implementation-specific behavior?
“Is it possible to to find out whether this was successful” For whom to find out? If you are talking about the implementation (or host specs) HostReportError is the mechanism the ES spec. uses to indicate that a point has been reached where extra lingual errors (i.e., errors that are not directly visible to ES code as exceptions) may be make manifest by the implementation.
(Note that while https://tc39.github.io/ecma262/#sec-toplevelmoduleevaluationjob <https://tc39.github.io/ecma262/#sec-toplevelmoduleevaluationjob> allows for eager parsing, linking, and even ModuleDeclarationInstantiations but also says that in the eager case “reporting” of the error must be deferred unto the appropriate step of TopLevelModuleEvaluation.)
This primarily is about TopLevelModuleEvaluationJobs that are initiated by the “host”. In an implementation exposes a module loader with an API that allows an ES program to dynamically load modules (essentially dynamically create TopLevelModuleEvaluationJobs) then then HostReportError action for such a job would presumably trigger whatever sort of error reporting mechanism exposed via the API (probably reject a promise).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss