Re: Error-Type Specific try/catch Blocks

I still can't see why it's superior to standardizing SpiderMonkey non-standard syntax. ``` try { ... } catch(e if e instanceof Error) { } ``` I think it's rather inferior, because your doesn't allow C#-like exception filters. It saves you 14 characters, but limits your "easy" filters to

Re: Error-Type Specific try/catch Blocks

Shiny... On Fri, May 27, 2016, 05:06 Arthur Stolyar wrote: > Something wrong with prev link. > https://github.com/zenparsing/es-typed-catch > On May 27, 2016 12:00, "Arthur Stolyar" wrote: > >> If something, here seems to be another similar

Re: Error-Type Specific try/catch Blocks

Something wrong with prev link. https://github.com/zenparsing/es-typed-catch On May 27, 2016 12:00, "Arthur Stolyar" wrote: > If something, here seems to be another similar proposal: > https://github.com/zenparsing/es-typed-catch >

Re: Error-Type Specific try/catch Blocks

If something, here seems to be another similar proposal: https://github.com/zenparsing/es-typed-catch ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Error-Type Specific try/catch Blocks

ntaxes, >>>>>> 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

Re: Error-Type Specific try/catch Blocks

gt; > catch (TypeError as e) {} >>>>> > >>>>> > // ... >>>>> > >>>>> > try {} >>>>> > catch (MyError as err) {} >>>>> > ``` >>>>> > >>>>> >> On Fri, May

Re: Error-Type Specific try/catch Blocks

On Fri, May 13, 2016 at 9:43 AM, Michał Wadas <michalwa...@gmail.com> >>>> wrote: >>>> >> I can't see why would your syntax be superior to SpiderMonkey >>>> extension >>>> >> except saving few characters. >>>> >>

Re: Error-Type Specific try/catch Blocks

> except saving few characters. >>> >> >>> >> Can your syntax support code like this: >>> >> >>> >> async function foo() { >>> >> try { >>> >> throw new Error(); >>> >> } catch

Re: Error-Type Specific try/catch Blocks

t;> >> // special handler for DOM exceptions >> >> } catch(e if e instanceof (await >> >> fancyClassLoader.load('classes/SomeLibrary/UserDefinedError'))) { >> >> // load class asynchronously if it wasn't loaded >> >> } >> >>

Re: Error-Type Specific try/catch Blocks

f 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

Re: Error-Type Specific try/catch Blocks

(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 >> } >> } >> >> ? >> >> &g

Re: Error-Type Specific try/catch Blocks

On 5/13/16 11:06 AM, Joseph Groseclose wrote: 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 I'd like to understand

Re: Error-Type Specific try/catch Blocks

fancyClassLoader.load('classes/SomeLibrary/UserDefinedError'))) { > // load class asynchronously if it wasn't loaded >} > } > > ? > > > On Fri, May 13, 2016 at 5:58 PM, Joseph Groseclose <jgrosec...@gmail.com> > wrote: >> >> I've updated the proposal. See: >

Re: Error-Type Specific try/catch Blocks

//github.com/benderTheCrime/error-type-specific-catch-proposal#about-spidermonkey-implementation > > On Fri, May 13, 2016 at 11:49 AM, Joseph Groseclose <jgrosec...@gmail.com> > wrote: > >> Nevertheless, perhaps the non-standard implementation could work >> hand-in-hand w

Re: Error-Type Specific try/catch Blocks

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 <jgrosec...@gmail.com> wrote: > Nevertheless, perhaps the non-standard implementation could wo

Re: Error-Type Specific try/catch Blocks

h Groseclose <jgrosec...@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 &g

Re: Error-Type Specific try/catch Blocks

>> Le 13 mai 2016 à 17:06, Joseph Groseclose <jgrosec...@gmail.com> a écrit : >> >> I sent this proposal via >> http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# >> yesterday evening. Sha

Re: Error-Type Specific try/catch Blocks

t; http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# > > <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-c

Re: The Error type

Le 17/08/2012 16:11, Brendan Eich a écrit : David Bruant wrote: Could what I just described implemented with value proxies? I'm not very familiar with the proposal. See http://disnetdev.com/talks/virtual_values.pdf and http://users.soe.ucsc.edu/~cormac/papers/oopsla11.pdf -- and probably

Re: The Error type

will read what's in it and choose to forward or alter the value or empty the fail channel. Based on this experience I'd like to suggest a slightly different approach to the error type. Since it's quite a different model (from what exists already and Peter's proposal) and may require major rewrite

The Error type

is not without a bit of irony, due to the nature of the Error type, which you can read below. Tl;dr the Error type would be instanceof the Error object (like strings are to String). It would have an internal property containing an error message, which can be empty. Comparison and coercion would