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


Tab Atkins Jr. <jackalmage@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |jackalmage@gmail.com

--- Comment #3 from Tab Atkins Jr. <jackalmage@gmail.com> ---
(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.

Countering this, I've written algos that could detect *some* of these types of
errors syncly, but others had to wait for async stuff to come in.  It's not
obvious a priori which types of mistakes fall into which category, as it's
intimately related to the details of the algorithm.  Having some TypeErrors and
similar things happen as thrown exceptions and others happen as rejected
promises is just all kinds of confusing.

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

Received on Monday, 4 August 2014 22:23:51 UTC