Comment #41 on issue 3093 by [email protected]: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Oh, and I forgot to add: I understand your frustration. I think shipping
promises as-is is equivalent to shipping a JS engine without a debugger or
any indication that script errors of any sort occurred. They are indeed
incomplete, by modern standards of developer tooling.
What you are proposing would move us into the analogy of the Netscape 3
days, where script errors would show up as alerts that the developer has to
dismiss, one by one, even if the errors are wrapped in try/catch.
It seems better to bypass that medieval era, and simply add a proper
promise debugger. One already exists as a Chrome extension for Ember's
promises, for example. We're not breaking new ground here; the UI and UX
are well-understood and well-charted.
In the meantime, before such Chrome extensions existed, people have
debugged promises using a variety of techniques, none of which were
optimal, but all of which alleviated their frustration. Promise users are
used to this. The situation is not unship-level drastic.
----
Ah, a response came in as I was typing.
Unlogging just sounds like a bad user experience to me. If you have the
console open you'd see the error flicker by.
Assuming you batched up changes to devtools with each microtask, you would
see no flicker unless the error was actually handled asynchronously, which
you claim is rare. (But again, in my experience it is common, especially in
UI-based code; often errors will not be handled until a user action, for
example.)
It's a deal-breaker if apps need to add rejection handlers to all their
promises in order to be able to capture JS errors to log back to the
server. window.onerror needs to work by default.
`window.onerror` is certainly not the right tool here, as in production
promise-using code such unhandled rejections will not be forever-unhandled,
but instead temporarily unhandled. A `window.onpossiblyunhandledrejection`,
preferably coupled with a `window.onrejectionhandled`, would be much more
accurate, and is what most promise libraries provide. (Bikeshed as you
please.)
Also remember that "all their promises" is not actually accurate; it's "all
their promise chains," of which there is generally only one per
asynchronous entry point into the application (i.e. main loop, event
handler, etc.). This is what makes strategies such as .done(), while sucky,
also feasible.
What are you suggesting as the solution? Do you think having the devtools
break on exception thing work better is actually sufficient? I don't.
A proper promise debugger, as in the Ember inspector, is what you really
need to be able to see the state of promises in your system. This includes
not just spurious unhandled rejections, but also forever-pending promises,
unhandled fulfillments, the flow of data between asynchronous entry points
along various chains, and so on. Unhandled rejections are the most painful
bit, and so if you want a quick patch to fix that frustration, a temporary
log entry that can be unlogged after handling is sufficient for that case.
But the rest are just as important. Soon enough you will be claiming
promises are unusable when you can't see your forever-pending promises.
I think break-on-rejection, if properly implemented (with modes for both
handled and unhandled-by-end-of-turn), would be a good thing, although it
would be roughly as useful as "break on all exceptions" given the number of
spurious false positives it would catch. And it's very easy to get wrong:
there's proposals upthread to make it only work for thrown errors, for
example, which would completely fail to catch other rejections (e.g. failed
database queries). But regardless, the actual primitive at hand is a live
list of promise rejections, and you need to give some insight into that.
For example, onunhandledrejection/onrejectionhandled helps reify this list,
by letting you send follow-up messages to your server saying that the
previously-reported rejection was actually handled after all. In effect,
this syncs the live list between client and server, emphasizing how the
live list is the actual primitive.
So I guess, if nothing else, my point is this: don't just focus on one half
of the live list. An ever-growing list of failures is not an accurate
reflection of the promise flow of a JS app.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
