Agreed. An exception being silently caught and ignored by es6-promise was the culprit of a bug hunt that took a lot longer than it could have if the exception had automatically percolated to the console. I know now about the infinite try-catch of Promise so it won't be as much of an issue, but I think it would be better if the exception were uncaught (or re-thrown) if there are no more handlers on the promise chain. (Not sure how the library would know that though)
Thats why bluebird eschews the ability to attach error handlers later in favor of logging errors from all rejected promises that don't have an error handler at the next turn of the event loop. The result is a much more pleasant development experience.
Yes, it was a bug. We did have code in place at the top level to catch unforeseen exceptions, but it didn't occur to us that we needed to do so inside the promise as well. We fixed the issue, but finding it was a lot harder than it needed to be because there was no indication of why something didn't work, only that it didn't.
