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 <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
