I can't speak for Benjamin, but I would like to "+1" the notion that
try/catches could benefit from some form of error pattern matching.  Here's
an example that attempts to avoid conflation with async control-flow
considerations:

```javascript
try {
    JSON.parse(getJSONString());
} catch (err) {
    if (err instanceof SyntaxError) {
        // handle the error
    } else {
        throw err;
    }
}
```

Discriminatory error handling like this is not all that uncommon, and could
potentially benefit from an expansion of the existing guards strawman [1].
 For example:

```javascript
try {
    JSON.parse(getJSONString());
} catch (err :: SyntaxError) {
    // handle the error
}
```

This of course has larger implications, though, as you'd presumably need to
support multiple "guarded" catches, and behavior for a failed guard is
different in the try/catch scenario than with parameters or properties.

[1] http://wiki.ecmascript.org/doku.php?id=strawman:guards


On Wed, Nov 20, 2013 at 10:24 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Benjamin (Inglor) Gruenbaum wrote:
>
>> Hi, thanks for the comment and sorry for the unclarity.
>>
>> I was refering to my original post in this thread about try/catch with
>> generators: http://esdiscuss.org/topic/try-catch-conditional-
>> exceptions-in-light-of-generators#content-0
>>
>
> Yes, but the Domenic pointed out that the reference error there has
> nothing to do with generators so much as async control flow in general (it
> could be in a function passed as a callback or downward funarg, and called
> "later" by any means). And you seemed to agreed.
>
> It's true that yield allows part of a function to run in a later event
> loop turn -- or just in a later iteration of a loop in the same turn.
> Generators by themselves are not async in the event loop sense. So first
> you need to identify the problem precisely.
>
> If you write
>
>   function f() { ... setCallback(function g() {... RefErrHere ... }) ... }
>
> you need test coverage over the body of g.
>
> If you write
>
>   function* f() { ... yield; RefErrHere ... }
>
> same deal. There is no difference in kind.
>
> So, is the problem you are citing a general one of test coverage over
> async control flow?
>
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131120/e69b8346/attachment.html>

I can't speak for Benjamin, but I would like to "+1" the notion that
try/catches could benefit from some form of error pattern matching.  Here's
an example that attempts to avoid conflation with async control-flow
considerations:

```javascript
try {
    JSON.parse(getJSONString());
} catch (err) {
    if (err instanceof SyntaxError) {
        // handle the error
    } else {
        throw err;
    }
}
```

Discriminatory error handling like this is not all that uncommon, and could
potentially benefit from an expansion of the existing http://wiki.ecmascript.org/doku.php?id=strawman:guards.
 For example:

```javascript
try {
    JSON.parse(getJSONString());
} catch (err :: SyntaxError) {
    // handle the error
}
```

This of course has larger implications, though, as you'd presumably need to
support multiple "guarded" catches, and behavior for a failed guard is
different in the try/catch scenario than with parameters or properties.