Re: try/catch/else

Oops, you're right. I agree that `else` might not be the best keyword for this all things considering. On Tue, Feb 13, 2018, at 1:48 PM, T.J. Crowder wrote: > On Tue, Feb 13, 2018 at 12:37 PM, Alan Plum <m...@pluma.io> wrote: > > Not quite. > > You appear to have missed my

Re: try/catch/else

rguments to `then`) Your reading wouldn't really provide anything that can't be done by simply moving the else block's content into the try block. -- Alan Plum m...@pluma.io On Tue, Feb 13, 2018, at 12:54 PM, T.J. Crowder wrote: > On Tue, Feb 13, 2018 at 11:30 AM, Isiah Meadows >

Re: try/catch/else

catch with `finally` (no pun intended) is this: does/should it > execute *before* or *after* else? > - > > Isiah Meadows > m...@isiahmeadows.com > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > &

Re: try/catch/else

: > On 02/08/2018 06:50, Alan Plum wrote: > > I realise there is some ambiguity in using the else keyword for this > > (though I can't think of a meaningful opposite of "catch" either). > > Indeed. You can't use 'else' without breaking existing behavior. For > exam

Re: Proposal to add keyword "nowait"

You could have a rule that could enforce always using `return await` in try/catch blocks in async functions. The `nowait` equivalent would be disabling that rule for that line. For the `nobreak` example I gave this actually exists (the rule is called `no-fallthrough` and could be disabled per

Re: Proposal to add keyword "nowait"

It sounds like what you want is basically a built-in syntax requirement that replaces what should be an eslint rule. For consistency this would mean JS should also have the keyword `nobreak` to prevent accidental switch/case fallthrough. Or you could just write an eslint rule for this (if one

Re: try/catch/else

The idea isn't to make the second call's exceptions silent, it's not to catch them (i.e. let them propagate).On 9 Feb 2018 2:46 p.m., Augusto Moura wrote:I see this operator quite confusing, in my opinion it's a best practice treat the functions (and errors) separately.

Re: try/catch/else

I think the best argument for having try/catch/else is that it makes it trivial to translate promises into async/await. Consider this: ``` let result = a() .then(b, c) .catch(d); ``` If we want to translate this 1:1 to try/catch/else in an async function we'll end up with something like this:

Re: try/catch/else

e might want to pass something from > `try` to it, just as promises do. Best way to do that might be for > `try` to act as an expression block and implicitly return the last > thing in it.> > On Thu, 8 Feb 2018 at 14:50 Alan Plum <m...@pluma.io> wrote: >> __ >> Hi everyo

try/catch/else

me overlap with conditional try/catch but I think this language feature is useful even if conditional try/catch exists. Cheers, Alan Plum ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss