__ at Christopher Thorn:__ I do see your point, but as pointed out by
__Peter Jaszkowiak__, there are already several little facilities
which have been added to JavaScript that are actually useful but could
relatively easily/straightforwardly be implemented in userland. This
particular feature (*i.e.*, filtered catch) is a very useful one that
I, like __Peter Jaszkowiak__ and likely lots of other folks, find
myself using *a lot*. In fact, there are at least a couple projects
where I've wanted to use Bluebird just due to the usefulness of that
feature alone and how clean it allows my code to be. Of course, we
don't want to add every potentially useful feature to the language,
but I think a case like this is a perfect example of when it makes
sense (*IMHO*).

On Wed, Oct 11, 2017 at 12:10 AM, Peter Jaszkowiak <p.jaszkow at gmail.com> wrote:
> True, it's a fairly trivial thing, but so is `Array.prototype.includes`. I
> can give a hundred other examples.
>
> There is a reason that so many people use underscore, ramda, lodash, etc:
> the "standard library" in Javascript is incomplete. We should aim to provide
> as many of these helpful utilities as possible. Not only does it improve
> developer experience, it also reduces payloads people need to download over
> the wire.
>
> I can understand why people are hesitant to add _syntactic additions_ to
> JavaScript, but when it comes to such useful cases that are already in wide
> use via libraries, I can't understand the reservations.
>
> You did provide a good method name (`guard`) if the final decision is to
> avoid overloading `catch` (which I don't mind either way, in some ways it
> would be preferable so the argument order could be reversed).
>
> Anyways, I think the best implementation would do three things:
>
> 1. If `matcher` is a function, check if `matcher.prototype instanceof
> Error`, if so, use `instanceof` to check if a rejected error matches
> 2. If `matcher` is a function that doesn't inherit from `Error`, execute it
> with the rejected error to get the match condition
> 3. If `matcher` is an object, check every own enumerable property against
> the rejected error to get the match condition
>
> This seems pretty complicated, in that it doesn't seem to match the
> principle of avoiding overloading in the standard library. I think in this
> case, removing any of this functionality is a significant loss, but if any
> were to be removed, I'd choose #3.
>
> Regards,
> Peter
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
- Jonathan

—

Life is a game and we’re all just high density pixels.

__@Christopher Thorn:__ I do see your point, but as pointed out by __Peter Jaszkowiak__, there are already several little facilities which have been added to JavaScript that are actually useful but could relatively easily/straightforwardly be implemented in userland. This particular feature (*i.e.*, filtered catch) is a very useful one that I, like __Peter Jaszkowiak__ and likely lots of other folks, find myself using *a lot*. In fact, there are at least a couple projects where I've wanted to use Bluebird just due to the usefulness of that feature alone and how clean it allows my code to be. Of course, we don't want to add every potentially useful feature to the language, but I think a case like this is a perfect example of when it makes sense (*IMHO*).