You don't need to sell me -- we had } catch (e if ...) { in SpiderMonkey
and proposed it for ES3 (in 1998, IIRC -- shaver did the work).
On the other hand, types (meaning static types) are not happening, as we
discus and re-discuss here often. Guards are not near consensus.
Refutable patterns are on the boards for ES7, also not near consensus:
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching
I'm still not clear how any of this helps Benjamin, but I don't quite
understand what Benjamin is running into.
/be
Jeremy Martin wrote:
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
