Add catch()
and finally()
, deprecate otherwise()
and always()
#208
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changeset adds new
catch()
andfinally()
methods to thePromiseInterface
and deprecates theotherwise()
andalways()
methods. The underlying idea is to renameotherwise()
tocatch()
andalways()
tofinally()
, but instead of performing a hard rename and causing a BC break, this changeset proposes deprecating the old method names and using them as an alias for the new method names.The original method names have been added in #19 a while back. Back then, using the
catch()
andfinally()
method names was not possible as using reserved keywords is only supported as of PHP 7+. Promise v3 is PHP 7.1+ only (#138 / #149), so we can now use the method names that mimic a synchronoustry
/catch
/finally
block. Additionally, this also happens to be in line with ES6 promises as found in JavaScript.Supersedes / closes #206, thanks @WyriHaximus for the original version! This PR follows the exact same idea with no functional difference, but adds additional documentation and duplicates all relevant test cases to achieve 100% code coverage for the affected code paths. Accordingly, there's a fair amount of duplication in the test suite now, which I consider a non-ideal but acceptable tradeoff. A potential promise v4 could remove this duplication at some point in the future.