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: Mon, 04 Aug 2014 21:20:27 +0000
To: public-script-coord@w3.org
Message-ID: <bug-26517-3890-KVmjMFK5Ve@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26517

--- Comment #2 from Jonas Sicking <jonas@sicking.cc> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 4 August 2014 21:20:30 UTC

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