ms odd given
> that synchronous database operations (your example) are extremely rare and
> in JavaScript. It seems to me like promises would fit this case pretty
> well, but I may have missed something.
>
> Ben
>
> Le jeu. 20 sept. 2018 05 h 32, Ayush Gupta a
> écrit :
>
&
teresting language feature I hadn't heard of before.
>
> Any reason your use case couldn't be covered by a try/catch in the
> synchronous case, and a promise.finally() in the async case?
>
> Ben
>
> Le jeu. 20 sept. 2018 05 h 21, Ayush Gupta a
> écrit :
>
>> Hi,
>&
be called
no matter when/if the function returns or throws
// do your work
}
```
Regards
Ayush Gupta
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
andard 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
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
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
In situations like this, I personally would use Event Emitters instead of
promises.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
7 matches
Mail list logo
