On Thu, Nov 13, 2014 at 7:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/thread.html#msg24
It seems in scope for the specification that defines window.onerror...
Someone is working on standardizing parts of the console API
On Thu, Nov 13, 2014 at 1:57 AM, Jeff Morrison lbljef...@gmail.com wrote:
Note that in my crazy idea I didn't say rethrow -- I carefully called it
out as more of a log than a throw.
I thought the plan was to have something equivalent to window.onerror
for promises.
--
On 11/13/14, 4:25 AM, Anne van Kesteren wrote:
On Thu, Nov 13, 2014 at 1:57 AM, Jeff Morrison lbljef...@gmail.com wrote:
Note that in my crazy idea I didn't say rethrow -- I carefully called it out as more of
a log than a throw.
I thought the plan was to have something equivalent to
On Thu, Nov 13, 2014 at 7:13 PM, Jeff Morrison lbljef...@gmail.com wrote:
I think that's what this discussion is about. Such a log could be
dispatched to window.onerror as well as console (etc).
Coming back to this after sleeping on it, though: The biggest problem I can
think of with my
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
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
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
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
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
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
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
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,
48 matches
Mail list logo
