W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 05 Aug 2014 07:17:10 +0000
To: public-script-coord@w3.org
Message-ID: <bug-26517-3890-H42qz1rsgj@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26517

Mounir Lamouri <mounir@lamouri.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mounir@lamouri.fr

--- Comment #4 from Mounir Lamouri <mounir@lamouri.fr> ---
(In reply to Jonas Sicking from comment #2)
> Yes, there seems to be different opinions of what makes good API design here.
> 
> In particular, people have expressed the opinion that having functions that
> can fail both synchronously and asynchronously means that developers that
> want to do error handling now have to "catch" errors in two different ways.
> And that this is a bad thing. Personally I've found this argument fairly
> convincing.
> 
> The strongest counter argument to me has been that some errors are due to
> runtime behavior and so makes a lot of sense to want to handle during
> runtime code. For example IO errors or users answering "no" in a security
> dialog.
> 
> Other errors are due to plain old bugs in the code which can make a certain
> line of code fail every single time. Such as forgetting to include all
> arguments, or using the wrong type for an argument. It's good if we can
> surface such errors as quickly as possible, and in a way that makes
> debugging as easy as possible.
> 
> However as long as developer tools gain knowledge about promises and can
> surface rejections as well as they traditionally have surfaced exceptions,
> then it seems like that takes care of this concern.

The only errors that can be reliably sync are the errors related to the
received input. If you expect a positive integer and get a negative one,
realising that should definitely be a synchronous operation. However, IO errors
or permissions errors might be sync or async as Tab pointed.

I agree with the others that having all errors rejecting the promise would make
everyone's life easier. Having to handle sync and async errors would make the
code harder to read and more complicated because there would be two code paths.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 5 August 2014 07:17:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC