On 10/08/2014 08:58 PM, Tab Atkins Jr. wrote:
On Wed, Oct 8, 2014 at 10:54 AM, Olli Pettay <o...@pettay.fi> wrote:
On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote:
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren <ann...@annevk.nl>
wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
<dome...@domenicdenicola.com> wrote:
What I find interesting here is the claim that people find try/catch
annoying or distasteful.
I don't think you should need try/catch for a common failure case.
That is all. So yes, agreed with Tobie et al.
You keep arguing from the future "rejections become errors" position.
You keep ignoring the past "turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody seems to complain" argument.
Do you dislike img.onerror firing when the image doesn't load? (And
same for all the other resource-loading elements.) Do you dislike
geolocator.getCurrentPosition calling the failure callback when the
user refuses permission? Do you dislike IDB firing error events on
several types of failure, ranging from exceptional to mundane?
If there are any of these you do *not* dislike, why? And why doesn't
the logic from those apply to this situation?
On Wed, Oct 8, 2014 at 9:18 AM, Domenic Denicola
<dome...@domenicdenicola.com> wrote:
Ah, this is the crux of our minor-disagreement, I think.
IMO using try/catch for a common failure case is fine, *as long as you
want that failure to bubble up the call stack*. E.g., if you want to handle
it at a higher level along with other failures, or if you want to ignore the
possibility of failure except in how errors get sent to `window.onerror`.
Now, I think we're likely in *agreement* that you don't actually want to
do this for requestPermission---you should handle it as soon as possible.
But our reasoning is different, and now I understand why.
The problem here is that try/catch *is* distasteful, while promise
rejection isn't, and it's all ergonomics.
* try/catch produces rightward drift, promise reject handlers do not
* errors bubble up indefinitely until they're caught, breaking all of
your code.
(off topic to Notifications)
That is a main point of exceptions. If your code is horribly broken,
like wrong params passed to some method, execution should stop asap.
The fact that Promise returning functions don't throw immediately is a crazy
setup
since one may just ignore and not notice at all the rather bad error in the
program logic.
As was stated in a recent bug thread you were participating in, we got
feedback from authors using IDB that they actually quite disliked
having to handle *some* errors via try/catch and *other* errors via
error callbacks, and would have preferred they all go through the
error callback.
One feedback to one API... that isn't really a strong argument.
"Fatal" errors indicating major issues in the program logic should be exposed
to the
scripts asap, not hidden to Promises (and probably not handled at all)
-Olli
~TJ
