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" <[email protected]> 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 <[email protected]> > 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" <[email protected]> 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 > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
