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 simple stuff shouldn't be made more
complex without justification. If we're going to do type guards like
that, we have to run it in the same tick as the subsequent block, then
for efficiency purposes, what's the point of the guard callback? For a
change this substantial, I'm not convinced it is broadly useful enough
(unlike exception handling with guarded `catch` blocks), especially
with async functions increasingly starting to replace most
promise-heavy code.
-----
Isiah Meadows
m...@isiahmeadows.com
Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
On Thu, Apr 26, 2018 at 2:11 AM, kai zhu <kaizhu...@gmail.com> wrote:
>
> On 26 Apr 2018, at 12:08 PM, Ayush Gupta <ayushg3...@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
> kaizhu...@gmail.com
>
>
> On Wed, Apr 25, 2018 at 10:25 PM, Bob Myers <r...@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 <track...@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 <isiahmead...@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 <ayushg3...@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@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
