Perhaps I worded it too strongly: I don't expect to get perfectly
prompt notifications of async exceptions. I don't think "pause on
uncaught exception" will ever work (to actually pause in the context
of where the exception occurred) for exceptions that are meant to be
forwarded.

What I'm saying is that by default we can throw the error when it's
accessed by `await`. If we restrict async functions to only be called
from other async functions, the engine should know if it's at the
top-level or not, and whether or not to put it on the deferred object
or to literally throw it (assuming the user didn't put try/catch
around it).

This only works if we don't make async functions return promises. This
is totally doable and just matter if there's enough consensus on it.

On Wed, Nov 12, 2014 at 10:13 AM, C. Scott Ananian
<ecmascr...@cscott.net> wrote:
> I think you're missing the point: you need to solve the halting problem if
> you expect to get prompt notification of asynchronous exceptions.  This
> can't be solved at a language level. The only solution is to expose the
> pending unhandled exceptions to programmers so that they can use their human
> judgment to determine when the exception has been pending "long enough" that
> it's actually an error. (And this isn't a new issue, or specific to promises
> or await/async.)
>
> GC of an promise tells you that some async exceptions can no longer be
> handled, but that's only part of the iceberg.  Promises can also be kept
> live indefinitely with unhandled exceptions.  That's not necessarily an
> error -- perhaps a handler will eventually be added.  Like I said, you need
> to solve the halting problem if you want to definitely identified unhandled
> asynchronous exceptions. The best solution is to expose the pending
> exceptions to the human, and let them decide.
>
> Please go back and reread the extensive discussions we've had on this topic
> previously on this mailing list.  I'm writing from my phone, but perhaps
> someone better connected can give you a few URLs.
>   --scott
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to