> On 26 Apr 2018, at 12:08 PM, Ayush Gupta <[email protected]> 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
[email protected]
>
> On Wed, Apr 25, 2018 at 10:25 PM, Bob Myers <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> [email protected] <mailto:[email protected]>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
> _______________________________________________
> es-discuss mailing list
> [email protected] <mailto:[email protected]>
> https://mail.mozilla.org/listinfo/es-discuss
> <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
