I agree this isn't ideal (it's a design hack that wasn't very well
thought through on the part of Bluebird IMHO), but not on your
justification (which comes across as borderline off-topic). Most
complex exception handling with promises are effectively handled using
async/await, but I agree the simp
> On 26 Apr 2018, at 12:08 PM, Ayush Gupta 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) => r
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(reaso
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 We
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 wrote:
> I'd still prefer we wait until pattern matching [1] gets addressed first,
> then tackling this. Error types are repre
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
err
We could potentially provide the same functionality in `try/catch` by
extending the signature of `catch` to
```js
try {
} catch(, ) {
}
```
If `` evaluates to truthy, invoke the `catch` block,
otherwise don't.
___
es-discuss mailing list
es-discuss@mo
For my part, if we're going to get into optional catching, I'd rather see a
common approach between promise `catch` and `try`/`catch`. There have been
various discussions about optional/filtered `catch` on the list ([here][1]
and [here][2], probably others).
Your approach is easily implemented in
I propose that in `Promises`, we accept another function which returns a
`boolean` as an argument to `catch`. It will enable us to write code like
this:
```js
return somePromise
.catch((reason) => reason instanceof ValidationError, reason =>
handleValidationError(reason)) // handle ValidationE
9 matches
Mail list logo
