> On Jul 20, 2016, at 8:47 AM, Jon Coppeard <[email protected]> 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).

Allen


_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to