- From: <bugzilla@jessica.w3.org>
- Date: Mon, 04 Aug 2014 21:20:27 +0000
- To: public-script-coord@w3.org
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