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.<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 25, 2018, 00:11 Ayush Gupta <<a href="mailto:ayushg3112@gmail.com">ayushg3112@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We could potentially provide the same functionality in `try/catch` by extending the signature of `catch` to<div><br></div><div>```js</div><div>try {</div><div><br></div><div>} catch(<expression_var>, <function_expression>) {</div><div><br></div><div>}</div><div>```</div><div><br></div><div>If `<function_expression>` evaluates to truthy, invoke the `catch` block, otherwise don't.</div></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>