RE: [whatwg] An API for unhandled promise rejections

Micah, you have been repeating your message in pretty much every promise-related thread, and I’ll say the same thing to you here that I’ve said there. You’re wrong. Promises model exception control flow. https://blog.domenic.me/youre-missing-the-point-of-promises/



From: Micah Zoltu [mailto:micah@zoltu.net]
Sent: Monday, May 25, 2015 22:39
To: public-whatwg@w3.org
Subject: Re: [whatwg] An API for unhandled promise rejections

I believe people (all over the internet, not just here) are mistaking promises for async/await.  While they look temptingly similar, they are fundamentally different and I believe that developers should wait for async/await and implementors should push forward with async/await implementations rather than breaking Promises.

When people see the following promise code:

```js
new Promise(executor).then(result => {
            doStuff();
}, error => {
            handleException();
});
```

They mistakenly think it is equivalent to this:

```js
try {
            executor();
            doStuff();
} catch {
            handleException();
}
```

However, it is actually equivalent to this:

```js
let resultOrError = executor();
switch (typeof resultOrError) {
            case result:
                        doStuff();
                        break;
            case error:
                        handleException;
                        break;
}
```

In the first visualization, one is seeing the error as an exception that stopped them from executing their primary code path.  In the second, the promise just provides a way to follow one of two code paths depending on success or failure.

What people desiring the first really want is async/await (ES7).

```js
try {
            await executor();
            doStuff();
} catch {
            handleException();
}
```

Promises do lay the groundwork for async/await, but they are should not be thought of as async await!  They are a generalized solution to a problem that can be expanded on in the future (via async/await) but solves multiple problems at the moment.

My problem with implementors logging on unhandled is that it drives developers away from using promises as promises and towards an incorrect (IMO) usage pattern of treating them like exception handling blocks.

Personally, in my development it is *incorrect* behavior to log an error on unhandled rejection.  An unhandled rejection just means that I don't have any business logic to run in the case of failure.  It does not mean I forgot something.

If implementors rush to log on failure without waiting for async/await, in a year we will end up with two things that solve the same problem (asynchronous exception handling) and nothing that solves the Promise problem.

I can support an event being fired that one can *opt-in* to listening to if they want, but baking in a log message on every unhandled rejection ruins Promises in my opinion and will inevitably drive me to third-party promise implementations.