Specification for catch / otherwise

[cullophid]

The biggest problem I find with using promises across multiple libraries is the inconsistent implementation of catch/otherwise.

otherwise is allot clearer than then(undefined, function), and makes your code much more radable.

[pkozlowski-opensource]

@cullophid are you saying that A+ spec should define .catch method as part of the spec and enforce it on all A+-complaint impls?

[cullophid]

Yes. In short. Its a cleaner api than .then(undefined, function).

Promise .then(func) .catch(func);

is more readable than Promise.then(func, func);

especially if you are passing anonymous functions :

Promise. then(function (result) { // do some stuff // if the promise is successfull }, function (err) { // do some stuff // if the promise is rejected });

Im not proposing that the reject method is removed from then ofc.

[domenic]

API convenience is not a goal of Promises/A+. Our goal is a minimal kernel of interoperability, as stated in the spec's intro paragraph.

---

From: Andreas Møllermailto:notifications@github.com Sent: ‎2014-‎08-‎01 06:07 To: promises-aplus/promises-specmailto:promises-spec@noreply.github.com Subject: Re: [promises-spec] Specification for catch / otherwise (#174)

Yes. In short. its a cleaner api than .then(undefined, function).

Promise.then(func) .catch(func);

is more readable than Promise(func, func);

Im not proposing that the reject method is removed from then ofc.

— Reply to this email directly or view it on GitHubhttps://github.com/promises-aplus/promises-spec/issues/174#issuecomment-50868737.

[petkaantonov]

A+ spec is not an API but IPPI (inter-promise programmable interface) , the API documented by the implementation you use is the API.

[cullophid]

@domenic fair point :)

[bergus]

@cullophid:

promise.then(func).catch(func); is more readable than promise.then(func, func);

Notice that it's also substantially different: