Re: try/catch/else

message three minutes later, after I'd > realized that: > https://esdiscuss.org/topic/try-catch-else#content-16 > > -- T.J. Crowder ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: try/catch/else

On Tue, Feb 13, 2018 at 12:37 PM, Alan Plum <m...@pluma.io> wrote: > Not quite. You appear to have missed my message three minutes later, after I'd realized that: https://esdiscuss.org/topic/try-catch-else#content-16 -- T.J. Crowder ___ e

Re: try/catch/else

Not quite. If the `else` (or `nocatch`, whatever) block throws, it would bypass the `catch` block but still hit the `finally` block the same way an exception in the `catch` block would: * if `a` doesn't throw: a, b, d * if `a` throws: a, c, d * if `b` throws: a, b, d * if `a` and `c` throw: a, c,

Re: try/catch/else

On Tue, Feb 13, 2018 at 11:54 AM, T.J. Crowder wrote: > > Then > > * If `a` doesn't throw: a, b, d. > * If `a` throws: a, c, d. > * If `b` throws: a, b, c, d > * If `a` and `c` both throw: a, c, d > * If `b` and `c` both throw: a, b, c, d Gah, I forgot that you

Re: try/catch/else

On Tue, Feb 13, 2018 at 11:30 AM, Isiah Meadows wrote: > > If you did `else` before `catch`/`finally`, that'd solve your problem. ;-) > > The catch with `finally` (no pun intended) is this: does/should it > execute *before* or *after* else? Logically it makes sense

Re: try/catch/else

Going with python's semantics, finally should execute after else because else behaves analogous to catch. It's basically a "nocatch". On Tue, Feb 13, 2018, at 12:30 PM, Isiah Meadows wrote: > If you did `else` before `catch`/`finally`, that'd solve your problem. ;-) > > The catch with `finally`

Re: try/catch/else

If you did `else` before `catch`/`finally`, that'd solve your problem. ;-) The 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

Re: try/catch/else

Yikes, thanks for pointing that out. I guess this could be resolved by having a lower precedence for `catch/else` than `if/else` or by enforcing the sequence `try/else/catch` (as `try` without `catch` or `finally` is a syntax error). On Tue, Feb 13, 2018, at 2:06 AM, Waldemar Horwat wrote: >

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 example: if (foo) try {...} catch (e) {...}

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 see this operator quite confusing, in my opinion it's a best practice treat the functions (and errors) separately. If you want to ignore the second error you can even create a `silent` helper. ```js const treatedShowSuggestions = (suggs) => { try { showSuggestions(suggs); } catch (e) {

Re: try/catch/else

> Le 9 févr. 2018 à 00:19, Peter van der Zee a écrit : > >>> On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache >>> wrote: What about the following pattern (labelled block + break)? ```js processSuggestions: { let

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

Re: try/catch/else

iled to load suggestions'); } showSuggestions(suggestions); } ``` This is almost identical, especially the way the example was written. I understand the differences, I don't think they're a problem for by far most cases where you'd want this. That said I wouldn't mind seeing try/catch/else/finally

Re: try/catch/else

I honestly wish engines (read: V8) didn't jave so much issue optimizing that. But yes, it's a very useful pattern. On Thu, Feb 8, 2018, 14:35 Mark Miller wrote: > Hi Claude, that's nice. Whenever I faced this issue I always turned to the > boolean flag variable. But this is

Re: try/catch/else

Hi Claude, that's nice. Whenever I faced this issue I always turned to the boolean flag variable. But this is strictly better. I expect to use it from now on. Thanks! On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache wrote: > What about the following pattern (labelled block

Re: try/catch/else

What about the following pattern (labelled block + break)? ```js processSuggestions: { let suggestions; try { suggestions = await fetchSuggestions(); } catch (e) { alert('Failed to load suggestions'); break processSuggestions; } showSuggestions(suggestions);

Re: try/catch/else

Sounds good in principle but I think the name is misleading. Actually try/catch/else is the synchronous equivalent of tryFn().then(elseFn, catchFn) but then has other implications (it returns a new promise and the then method actually takes two functions). Calling it then would imply it's

Re: try/catch/else

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 everyone, > > I'm hoping this is the right medium to ask this but I would like to > propose a language featur

try/catch/else

Hi everyone, I'm hoping this is the right medium to ask this but I would like to propose a language feature called try/catch/else. Conditional try/catch seems to be all the rage right now but in many cases the problem it really wants to solve seems to be code like the following: try { const