jonathan at belairlabs.com
Wed Oct 11 07:45:00 UTC 2017
__ at Christopher Thorn:__ I do see your point, but as pointed out by
__Peter Jaszkowiak__, there are already several little facilities
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
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:
> 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
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
Life is a game and we’re all just high density pixels.
More information about the es-discuss