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

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

Marcos Caceres <w3c@marcosc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |w3c@marcosc.com

--- Comment #6 from Marcos Caceres <w3c@marcosc.com> ---
(In reply to Olli Pettay from comment #5)
> The platform effectively has this behavior in non-Promise cases, like
> XHR.send().
> Success is reported via load event, some errors via error via and in some
> cases the method throws.
> 
> And, throwing early when the state of the object is wrong sounds right to me.
> Requiring to use reject for that is overkill.

If you read over [1], you will see plenty of justification as to why having two
separate modes of error handling is a bad idea. Basically this is a sad
pattern:

```
try{
   var promise = foo().then(whatever).catch( asyncErrorHandler )
}catch(e){
    syncErrorHandler(e)
}
window.onerror = moarErrorHandling
```

I feel strongly that what we currently have specified in WebIDL is most sane. I
did originally hold Hixie's position (that it's pretty easy to do all the
necessary type checks through WebIDL before crossing the async boundary - and
that it's traditionally not how the API's of the web work), but have been
convinced we should just let the promise machinery handle the rejection.
Primarily, unhandled errors are showing up in the error console of browsers, so
it's trivial enough for web devs to catch and fix them during development.

[1] https://github.com/domenic/promises-unwrapping/issues/24

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

Received on Tuesday, 5 August 2014 14:55:37 UTC