@JoePea, that is one of the syntaxes I recommend in the proposal. 

@michalwadas The primary goal of this I think is to create a standard feature, but I do not see why an expression wrapped in parenthesis ultimately resulting in an error class would not be supported.

Example:

...

} catch (await FCL.load(...), await FCL.load(...)) (e) {
...

Or something similar for all of the other recommended syntaxes, replacing the declared class instead with an expression (similar to class extension).

Sent from my iPhone

> On May 13, 2016, at 12:54 PM, /#!/JoePea <joe at trusktr.io> wrote:
> 
> Perhaps a syntax based on modules:
> 
> ```js
> try {}
> catch (TypeError as e) {}
> 
> // ...
> 
> try {}
> catch (MyError as err) {}
> ```
> 
>> On Fri, May 13, 2016 at 9:43 AM, Michał Wadas <michalwadas at gmail.com> wrote:
>> I can't see why would your syntax be superior to SpiderMonkey extension
>> except saving few characters.
>> 
>> Can your syntax support code like this:
>> 
>> async function foo() {
>>   try {
>>      throw new Error();
>>   } catch(e if isNativeException(e)) {
>>     // special handler for DOM exceptions
>>   } catch(e if e instanceof (await
>> fancyClassLoader.load('classes/SomeLibrary/UserDefinedError'))) {
>>      // load class asynchronously if it wasn't loaded
>>   }
>> }
>> 
>> ?
>> 
>> 
>> On Fri, May 13, 2016 at 5:58 PM, Joseph Groseclose <jgrosecl49 at gmail.com>
>> wrote:
>>> 
>>> I've updated the proposal. See:
>>> https://github.com/benderTheCrime/error-type-specific-catch-proposal#about-spidermonkey-implementation
>>> 
>>> On Fri, May 13, 2016 at 11:49 AM, Joseph Groseclose <jgrosecl49 at gmail.com>
>>> wrote:
>>>> 
>>>> Nevertheless, perhaps the non-standard implementation could work
>>>> hand-in-hand with the proposal, where SpiderMonkey could support both
>>>> solutions in parallel for backward compatibility. I think that the proposed
>>>> solution is more expressive.
>>>> 
>>>> On Fri, May 13, 2016 at 11:26 AM, Claude Pache <claude.pache at gmail.com>
>>>> wrote:
>>>>> 
>>>>> Note that SpiderMonkey has already nonstandard conditional catch
>>>>> clauses:
>>>>> 
>>>>> ```js
>>>>> try {
>>>>>    // ...
>>>>> }
>>>>> catch (e if e instanceof TypeError) {
>>>>>    // ....
>>>>> }
>>>>> ```
>>>>> 
>>>>> —Claude
>>>>> 
>>>>> 
>>>>> Le 13 mai 2016 à 17:06, Joseph Groseclose <jgrosecl49 at gmail.com> a écrit
>>>>> :
>>>>> 
>>>>> I sent this proposal via
>>>>> http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php#
>>>>> yesterday evening. Sharing it here now:
>>>>> https://github.com/benderTheCrime/error-type-specific-catch-proposal
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> 
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>

@JoePea, that is one of the syntaxes I recommend in the proposal. 

@michalwadas The primary goal of this I think is to create a standard feature, but I do not see why an expression wrapped in parenthesis ultimately resulting in an error class would not be supported.

Example:

```
// ...

} catch (await FCL.load(...), await FCL.load(...)) (e) {
// ...
```

Or something similar for all of the other recommended syntaxes, replacing the declared class instead with an expression (similar to class extension).

Sent from my iPhone