Finalize catch/then semantics

[AndrewBarba]

One of the hardest challenges of a Promise implementation in a strongly typed language is the semantics of catch and how it affects the Promise chain:

Promise/A+ 2.2.7.1
If either onFulfilled or onRejected returns a value x, run the Promise Resolution Procedure Resolve(promise2, x)

With this requirement, any then called directly after a catch does not know the Type of the first argument in it's handler. If the prior Promise resolves, then it will be the resolution of that Promise, but if it rejects it will be whatever value the catch returns. This unknown makes it impossible to implement directly in a typed language and forces us to make tradeoffs either with more functions (different names that explicitly indicate which behavior they implement) or making the resolution type less strict perhaps by using an optional type or a Any and then forcing unwrapping in the then handler.

I'm curious what the community's thoughts are on this before changing the semantics again in this library. If/when there is a good solution I will release a new version of the library as 2.0.0.

For reference, the current implementation provides 2 functions: catch and catchThen:

• catch allows for catching an error and continuing the promise chain as Promise<Void>. Whether the prior promise resolves/rejects, the then handler after a catch will always be run.
• catchThen forces the handler to recover with the same result Type as the original Promise. This means that if the original Promise resolves we can pass that result down to any then handlers after the catch and if it rejects the catch will be responsible for providing an alternate resolution of the same type.

[AndrewBarba]

Decided to use catch() to end the chain and recover() to recover from the chain