Hi James,
As you point out, exception swallowing is a problem for promises in
general. The best way to approach the issue as it applies to async/await
is to just solve it for promises. The current direction JS engines are
taking is to log unhandled rejections in one way or another. I would
On Wed Nov 12 2014 at 1:33:52 AM James Long longs...@gmail.com wrote:
After a brief twitter conversation last night
(https://twitter.com/lbljeffmo/status/532402141001179136) I thought
I'd post some thoughts I've been having about async/await.
I feel like I'm about to walk into a pit where
Not sure of the best way to reply to both emails, guess I'll just
inline both here:
On Wed, Nov 12, 2014 at 8:38 AM, Kevin Smith zenpars...@gmail.com wrote:
Hi James,
As you point out, exception swallowing is a problem for promises in general.
The best way to approach the issue as it applies
Actually, it is possible we can do this without any extra syntax at
all (no `await^`). If we restrict async functions to only be able to
be called by other async functions, the engine should be able to keep
track of the async stack and throw errors appropriately up the chain,
and know when it hits
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
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
Actually, it is possible we can do this without any extra syntax at
all (no `await^`). If we restrict async functions to only be able to
be called by other async functions, the engine should be able to keep
track of the async stack and throw errors appropriately up the chain,
and know when
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.
Well, that's not really going to happen, though. Async functions will be
promise-based: it's a core design feature.
Again, this is a generic issue for promises: a good solution there will
fix everything.
It's inherent in the promise design, there is no way to truly fix
promises. You have to mark the end of a promise chain. It's always
going to be that way.
My preferred solution to this problem: modify
From: Tyler Breisacher tbreisac...@google.com
To: es-discuss@mozilla.org
Cc:
Date: Mon, 10 Nov 2014 10:07:52 -0800
Subject: How are module specifiers resolved?
As far as I can tell, the ECMAScript spec doesn't answer this directly.
The HostNormalizeModuleName section says: The actual
It's inherent in the promise design, there is no way to truly fix
promises. You have to mark the end of a promise chain. It's always
going to be that way.
So you're starting from the position that promises are inherently flawed
and should be abandoned. That's not really constructive
On Wed, Nov 12, 2014 at 10:46 AM, Kevin Smith zenpars...@gmail.com wrote:
It's inherent in the promise design, there is no way to truly fix
promises. You have to mark the end of a promise chain. It's always
going to be that way.
So you're starting from the position that promises are
The subject is a SpiderMonkey bug.
Is that really desirable? Doesn’t it invalidate the Proxy’s role as an
interceptor?
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
On 12 Nov 2014, at 16:33, James Long longs...@gmail.com wrote:
Again, this is a generic issue for promises: a good solution there will
fix everything.
It's inherent in the promise design, there is no way to truly fix
promises. You have to mark the end of a promise chain. It's always
On Wed, Nov 12, 2014 at 11:08 AM, Axel Rauschmayer a...@rauschma.de wrote:
Is that true, though? Couldn’t a finalizer or something similar check
(before a promise is garbage collected) whether all errors have been
handled?
A finalizer can do this check. This will flag some uncaught
I agree with your sentiment. I have previously advocated that Array.isArray
should be transparent for proxies. My harmony-reflect shim explicitly
differs from the spec on this point because people using the shim
spontaneously reported this as the expected behaviour and thought it was a
bug that
On Wed, Nov 12, 2014 at 6:17 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Nov 12, 2014 at 11:08 AM, Axel Rauschmayer a...@rauschma.de
wrote:
Is that true, though? Couldn’t a finalizer or something similar check
(before a promise is garbage collected) whether all errors have
On Wed, Nov 12, 2014 at 12:11 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Actually that already works, at least in Chrome, if you execute
(function () {
return new Promise(function (resolve, reject) {
reject(new Error(foo));
});
}());
That's a false positive though.
On Wed, Nov 12, 2014 at 12:15 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 12:11 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Actually that already works, at least in Chrome, if you execute
(function () {
return new Promise(function (resolve, reject) {
On Wed, Nov 12, 2014 at 12:18 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
What happens if you attach an error handler to x. Does the console
warning go away? (It should.)
--scott
It does not. I think that would be weird, but I've heard the idea of
graying out the logged error which
On 11/12/14, 11:08 AM, Axel Rauschmayer wrote:
Is that true, though? Couldn’t a finalizer or something similar check
(before a promise is garbage collected) whether all errors have been
handled?
It can, but then what? How do you report the rejection value in that
finalizer? In your typical
On 11/12/14, 9:49 AM, James Long wrote:
Yes, I have (I work on the Firefox devtools). The best we can do (as
far as I know) is log an error when a promise is GC-ed with an
unhandled error
Note that this is what Firefox does right now, but we're moving away
from that to a report if the event
Le 12/11/2014 17:23, Tom Van Cutsem a écrit :
I agree with your sentiment. I have previously advocated that
Array.isArray should be transparent for proxies. My harmony-reflect
shim explicitly differs from the spec on this point because people
using the shim spontaneously reported this as the
In my year long experience with large code bases using Bluebird promises which
do unhandled rejection tracking - I haven't had a single false positive or
false negative.
Adding error handlers asynchronously is in practice extremely rare.
On Nov 12, 2014, at 19:15, James Long
On Wed, Nov 12, 2014 at 11:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is worth
the exception.
I agree and I want to know if you think this is worth revisiting once more?
Next meeting's agenda?
Rick
2014-11-12 19:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
I agree and I want to know if you think this is worth revisiting once
more? Next meeting's agenda?
I don't think we've ever discussed this issue before during a TC39 meeting
(but I didn't attend quite a few, so I may be wrong).
In general, it appears that SM unwraps proxies so that internal slot access
is transparently forwarded. I don't see any such unwrapping in the ES spec
though. I assume that the spec is correct?
___
es-discuss mailing list
es-discuss@mozilla.org
On Wed, Nov 12, 2014 at 2:12 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-11-12 19:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
I agree and I want to know if you think this is worth revisiting once
more? Next meeting's agenda?
I don't think we've ever discussed this issue before
My opinion is that array testing is fundamental to core JS and is worth
the exception.
Knowing that Array.isArray() tests fail for proxies, I'd be afraid to ever
create a Proxy for an array that I don't control the complete lifecycle of.
That seems to critically inhibit the usefulness of
Even if async functions are changed to only be callable from an async
context or toplevel, they could still be promise-based from an
implementation's point of view.
The only thing they couldn't do (under this proposal) is expose the
promise being used to userland (to eliminate the chance for
On 11/12/14, 9:57 AM, James Long wrote:
Actually, it is possible we can do this without any extra syntax at
all (no `await^`). If we restrict async functions to only be able to
be called by other async functions, the engine should be able to keep
track of the async stack and throw errors
The only thing they couldn't do (under this proposal) is expose the
promise being used to userland (to eliminate the chance for userland to
hold on to the promise and expect to be able to add an error handler at any
time).
And lose the ability to combine the results of async functions with
On Wed, Nov 12, 2014 at 1:10 PM, Kevin Smith zenpars...@gmail.com wrote:
The only thing they couldn't do (under this proposal) is expose the
promise being used to userland (to eliminate the chance for userland to hold
on to the promise and expect to be able to add an error handler at any
On 11/12/14, 4:10 PM, Kevin Smith wrote:
The only thing they couldn't do (under this proposal) is expose
the promise being used to userland (to eliminate the chance for
userland to hold on to the promise and expect to be able to add an
error handler at any time).
And lose the
On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison lbljef...@gmail.com wrote:
On 11/12/14, 4:10 PM, Kevin Smith wrote:
The only thing they couldn't do (under this proposal) is expose the
promise being used to userland (to eliminate the chance for userland to hold
on to the promise and expect to be
If Array.isArray should fail for non pure Arrays, can we have a
Proxy.isProxy that never fails with proxies ?
At least this would give a better idea on what's eventually going on:
```js
if (Array.isArray(obj) !Proxy.isProxy(obj)) {
// ... ok, pure Array, no magic wrappers
}
```
Regards
On
On 11/12/14, 5:23 PM, Tab Atkins Jr. wrote:
On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison lbljef...@gmail.com wrote:
On 11/12/14, 4:10 PM, Kevin Smith wrote:
The only thing they couldn't do (under this proposal) is expose the
promise being used to userland (to eliminate the chance for
On 11/12/14, 5:49 PM, Jeff Morrison wrote:
The problem with the GC-based logging is only that it doesn't work all
the time...and for non-obvious reasons.
That's not the only problem. It's also very problematic to implement
without imposing nasty constraints on your GC.
-Boris
On Wed, Nov 12, 2014 at 2:49 PM, Jeff Morrison lbljef...@gmail.com wrote:
On 11/12/14, 5:23 PM, Tab Atkins Jr. wrote:
On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison lbljef...@gmail.com
wrote:
Crazy, half-baked idea: Move the forwards vs throws/logs distinction
to
the callsite (in sync
On Wed, Nov 12, 2014 at 5:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
It's impossible to rethrow errors without use of await - the error
may happen in a different turn entirely than the function call. You
*must* convert your calling function into an async one, so that it can
do the
On Wed, Nov 12, 2014 at 3:06 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 5:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
It's impossible to rethrow errors without use of await - the error
may happen in a different turn entirely than the function call. You
*must*
On Wed, Nov 12, 2014 at 6:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
No, you're misunderstanding me, or the way that async stuff works.
Calling an async function returns immediately. The called function
doesn't actually run until a later turn. If it throws, there's *no
way*, even
On Wed, Nov 12, 2014 at 3:29 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 6:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
No, you're misunderstanding me, or the way that async stuff works.
Calling an async function returns immediately. The called function
doesn't
On Wed, Nov 12, 2014 at 6:34 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 3:29 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 6:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
No, you're misunderstanding me, or the way that async stuff works.
On Wed, Nov 12, 2014 at 3:36 PM, James Long longs...@gmail.com wrote:
`await` is *always* inside an `async` function so there's always a
promise created for that function which is waiting for it to be done
executing. That's the one I'm talking about.
Okay. That doesn't change my response.
On Wed, Nov 12, 2014 at 6:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 3:36 PM, James Long longs...@gmail.com wrote:
`await` is *always* inside an `async` function so there's always a
promise created for that function which is waiting for it to be done
executing.
On Wed, Nov 12, 2014 at 3:53 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 6:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 3:36 PM, James Long longs...@gmail.com wrote:
`await` is *always* inside an `async` function so there's always a
promise
On Wed, Nov 12, 2014 at 6:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 3:53 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 6:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 3:36 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 4:07 PM, James Long longs...@gmail.com wrote:
Maybe this would be resolved if you could answer this: how do you mark
an async function to be a top-level one? I don't see anywhere that
says I don't return a promise, I want errors inside of me to
literally throw. I am an
On Wed, Nov 12, 2014 at 7:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 4:07 PM, James Long longs...@gmail.com wrote:
Maybe this would be resolved if you could answer this: how do you mark
an async function to be a top-level one? I don't see anywhere that
says I
On Wed, Nov 12, 2014 at 4:18 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 7:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 4:07 PM, James Long longs...@gmail.com wrote:
Maybe this would be resolved if you could answer this: how do you mark
an
On Wed, Nov 12, 2014 at 7:24 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Marking a function as top-level is just syntax sugar for calling
.done() on the returned promise. (Assuming that .done() can forward
rejections to window.onerror.) It might be useful, I dunno, but it
doesn't offer
On Wed, Nov 12, 2014 at 7:28 PM, James Long longs...@gmail.com wrote:
On Wed, Nov 12, 2014 at 7:24 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Marking a function as top-level is just syntax sugar for calling
.done() on the returned promise. (Assuming that .done() can forward
rejections to
Hey ES6ers,
I'm currently implementing some of the ES6 support for the next version of
TypeScript. The part I'm looking at right now is generators and yield
expressions. So far we feel fairly comfortable with the grammar and understand
the implications of the [Yield] and
Note that in my crazy idea I didn't say rethrow -- I carefully called it out
as more of a log than a throw.
Sent from my iPhone
On Nov 12, 2014, at 5:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 2:49 PM, Jeff Morrison lbljef...@gmail.com wrote:
On 11/12/14,
2014-11-12 20:37 GMT+01:00 Kevin Smith zenpars...@gmail.com:
In general, it appears that SM unwraps proxies so that internal slot
access is transparently forwarded. I don't see any such unwrapping in the
ES spec though. I assume that the spec is correct?
This auto-unwrapping for internal
2014-11-12 23:49 GMT+01:00 Andrea Giammarchi andrea.giammar...@gmail.com:
If Array.isArray should fail for non pure Arrays, can we have a
Proxy.isProxy that never fails with proxies ?
We ruled out `Proxy.isProxy` very early on in the design. It's antithetical
to the desire of keeping proxies
On 12 November 2014 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is
worth the exception.
This change would only make sense if we also were to special-case all
other places in the spec that currently say if O is an exotic Array
2014-11-12 20:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
Done https://github.com/tc39/agendas/blob/master/2014/11.md
Thanks. A related point: my harmony-reflect shim also patches
Array.prototype.concat such that it recognizes proxies-for-arrays and will
splice their elements (rather
2014-11-13 8:18 GMT+01:00 Andreas Rossberg rossb...@google.com:
On 12 November 2014 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is
worth the exception.
This change would only make sense if we also were to special-case all
60 matches
Mail list logo
