So in the first function you call reject, but in the second function you throw? I don't love the asymmetry.

Also how do you return a value from the second callback? Just return?

If throw and return work that way for then() functions, why not the same for the initial function?

Because the initial one is where you'd interface (potentially) with non-promise code. E.g. in order to wrap a node-style function, you can't throw or return. But in general you shouldn't need to use `new Promise()`, that should in most cases be reserved to more general, low-level code (e.g. a promisify implementation).

I'm writing code against indexedDB (which doesn't use promises), but I want to expose promises to my callers. So I'm wrapping my indexedDB usage in Promises.

Also some of indexedDB doesn't seem like it would fit with promises, since some operations have 3 or more callbacks (onsuccess, onerror, onupgradeneeded).

There are a number of IndexedDb libraries that uses promises. However, there is or was a problem with how IndexedDb is specified to work that is not really compatible with promises. I'm not sure if they have fixed this yet. https://github.com/promises-aplus/promises-spec/issues/45#is...

Interesting info, thanks for the pointer!

I can see the benefits of the indexedDb behavior: an open transaction is an exclusive resource, so leaving one dangling locks out other transactions. The auto-commit behavior means it's a lot harder to accidentally leave a transaction dangling. But it is unfortunate that this makes it not play nicely with promises.

Or better, Promise.reject

Both are useful, but I'd hesitate to call it better. What makes you say it is better?

It makes explicit that the intention that a promise should be rejected, as opposed to a throw where one might reasonably expect an exception of some sort.