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.