Proposal: Conditional `catch` in Promises

[kai zhu]

> On 26 Apr 2018, at 12:08 PM, Ayush Gupta <ayushg3112 at gmail.com> wrote:
> 
> It might be worth **explicitly** mentioning that it's not about types either, the benefit with using functions as the filter is that we can tackle a lot of cases. Consider this:
> 
> ```js
> return somePromise
>     .catch((reason) => reason instanceof ValidationError, reason => handleValidationError(reason))
>     .catch((reason) => reason.code === 'ENOENT', reason => handleENOENT(reason))
>     .catch(reason => handleOtherErrors(reason)) // catch all others
> ```
> 

can someone give a sane javascript styleguide on when to use the above and when to use this code below?  otherwise, we’re simply adding to the industry-painpoint of the language having too many cross-cutting design-patterns, leading to hard-to-maintain web-projects with inconsistent code across its components.

```js
return somePromise
    .catch((function (reason) {
        if (reason instanceof ValidationError) {
            return handleValidationError(reason);
        }
        if (reason.code === 'ENOENT') {
            return handleENOENT(reason);
        }
        return handleOtherErrors(reason)) // catch all others
    });
```

kai zhu
kaizhu256 at gmail.com

> 
> On Wed, Apr 25, 2018 at 10:25 PM, Bob Myers <rtm at gol.com <mailto:rtm at gol.com>> wrote:
> What do you mean by "approach TypeScript"? Do you mean propose this feature to the TS team? TS is not about new language features (with a few exceptions). It's about typing. They're quite careful about not forking the language.
> 
> >  Not sure if that supports typed errors
> 
> No, it doesn't.
> 
> Bob
> 
> On Wed, Apr 25, 2018 at 9:49 PM, Michael J. Ryan <tracker1 at gmail.com <mailto:tracker1 at gmail.com>> wrote:
> Maybe approach typescript on this one... Not sure if that supports typed errors like C# does, but would probably suit you well.
> 
> On Wed, Apr 25, 2018, 08:31 Isiah Meadows <isiahmeadows at gmail.com <mailto:isiahmeadows at gmail.com>> wrote:
> I'd still prefer we wait until pattern matching [1] gets addressed first, then tackling this. Error types are represented about 50 different ways in JS, with subtyping only being one (used by the standard kind of). Node appends an `err.code`, and the DOM adds a similar type, just using a common error subclass. And in some cases where errors are planned (but exceptions are more convenient), you sometimes see non-errors thrown. So there needs to be a means of catching all of them, and `if` checks get verbose and noisy in a hurry.
> 
> On Wed, Apr 25, 2018, 00:11 Ayush Gupta <ayushg3112 at gmail.com <mailto:ayushg3112 at gmail.com>> wrote:
> We could potentially provide the same functionality in `try/catch` by extending the signature of `catch` to
> 
> ```js
> try {
> 
> } catch(<expression_var>, <function_expression>) {
> 
> }
> ```
> 
> If `<function_expression>` evaluates to truthy, invoke the `catch` block, otherwise don't.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <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/20180426/9f2698ad/attachment.html>