[Bug 26517] Methods that return promises are unable to throw exceptions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26517

--- Comment #8 from Marcos Caceres <w3c@marcosc.com> ---
(In reply to Ian 'Hixie' Hickson from comment #7)
> If you read over [1], you will see plenty of justification as to why having
> only one mode of error handling is a bad idea too.
> Let's not pretend that
> there's any kind of consensus on this issue, either. Plenty of people
> commented on that issue in agreement with the idea that we shouldn't turn
> type checks into promise rejections.

True. Strong arguments are made on both sides - just saying that I personally
landed on a particular side. 

I'm asking that those that are participating in this discussion consider the
arguments very carefully because what you are asking to change here has massive
implications (for both shipping and all future APIs that rely on promises). 

> All this bug is asking for is the ability to write IDL without having to
> have hacks to sidestep this exception-wrapping nonsense.

No, that's not all this bug is asking for: it has the potential to have
significant implications for implementers, spec editors, and authors. If we get
some in-between option, like "[throwOnInvalidInput]" or whatever, then some
APIs might use this and others might not... then, as an author, you always need
to check the API contract (so to wrap in try/catch); as a spec Editor, you need
to decide if you want to use that and have a good justification as to why (and
we risk big f'ups, like with everyone copy/pasting [NoInterfaceObject] without
people understanding what it does); and as an implementer, you need to clearly
separate the async and sync checks - where right now promises just deal with it
(even if it's "exception-wrapping nonsense").  

> I would much rather
> be able to write:
> 
>    Promise<Foo> bar();
> 
> ...than have to write:
> 
>    interface Whatever { };
>    typedef (Promise<Foo> or Whatever) PromiseFoo;
> 
>    PromiseFoo bar();
> 
> ...which is what I'm currently forced to do to describe APIs that throw in
> certain cases and return promises when they don't throw.

IIUC, what we are trying to agree on is what model we use for the Web (what the
web used from the beginning of time or this new model that is currently in
WebIDL - or something in between, where there is a very good reason to not have
the promise handle the error through rejection). If you've managed to cleverly
hack around it using a typedef doesn't really address the core problem - as
whatever API you put that on may be rejected by implementers unless we get
agreement on the idiom to use.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 5 August 2014 18:48:23 UTC