Filtered Promise#catch

Peter Jaszkowiak p.jaszkow at gmail.com
Wed Oct 11 14:14:54 UTC 2017


If you're going to distinguish between "ergonomic" and "easy" in the
context of JavaScript development, you're going to have to define what you
think the difference is.

For something that should, imo, be used in almost every case that `catch`
is used, I don't think that it just being ergonomic to create your own
helper functions is enough. Are you going to create your own helper
function like that for every error type across every file?

Do you want the developer to provide their own `guard` etc helper functions
like you did? Why should they have to?

As I said before, I think the criticism of overloading is fine. However,
this is something more useful than `Array#includes` and already in use more
often than that Array method.

We can use different method names to separate different types of guards if
you feel like it's a preferable idea. However, it definitely needs to be
done because there is significant demand demonstrated by many people still
using bluebird for these utility functions.

On Oct 11, 2017 7:06 AM, "Christopher Thorn" <morphcham at gmail.com> wrote:

> I don't think it's pedantic to point out that you're misstating my
> argument. I didn't say "easy", I said "ergonomic", after all.
>
> I've used bluebird quite a lot, and I've also used native promises and
> other promise libraries without filtered catch. At first, I missed
> this feature from bluebird, but I no longer do.
>
> Personally, I prefer the ergonomics of helper functions like I
> demonstrated to an overloaded `catch` method, especially one which
> does different things depending on the types of the arguments that are
> passed (one behavior for the instanceof check, another for a function
> predicate and another for an object predicate). Using an separate
> function gives the user a chance to specify exactly the behavior they
> want, no more and no less, and gives the user a chance to name the
> filter.
>
> Regards,
> Chris
>
> On Wed, Oct 11, 2017 at 5:28 AM, Michał Wadas <michalwadas at gmail.com>
> wrote:
> > I don't get why argument "it's easy to implement in user land" is raised.
> >
> > All Array methods are easy to implement in user land. Including recent
> > additions like .includes and ES2015 methods.
> >
> > Promises are easy to implement in user land. Smallest implementation is
> less
> > than 1kB AFAIR.
> >
> > Maps, Sets, WeakSets are trivial to implement in user land if WeakMap is
> > present. Probably less than 50 lines of code.
> >
> > Object.values, Object.entries, Object.assign,
> > Object.getOwnPropertyDescriptors, Object.is, Array.from, Array.of. These
> > methods were added recently but they can be implemented in user land.
> >
> > On 11 Oct 2017 2:28 am, "Christopher Thorn" <morphcham at gmail.com> wrote:
> >>
> >> I agree that catch guards are useful, but they can be implemented in
> >> userland fairly ergonomically:
> >>
> >> ```
> >> function guard(predicate, callback) {
> >>   return function guarded(reason) {
> >>     if (!predicate(reason)) {
> >>       throw reason;
> >>     }
> >>     return callback(reason);
> >>   };
> >> }
> >>
> >> function instanceOf(constructor, callback) {
> >>   return guard(reason => reason instanceof constructor, callback);
> >> }
> >>
> >> Promise.resolve('invalid')
> >>   .then(JSON.parse)
> >>   .catch(instanceOf(SyntaxError, reason => {
> >>     // do something to handle the syntax error, or perhaps just silence
> it
> >>   }));
> >> ```
> >>
> >> Regards, Chris
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171011/0afcec30/attachment-0001.html>


More information about the es-discuss mailing list