Re: try/catch/else

2018-02-13 Thread Alan Plum
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 wrote: > > Not quite. > > You appear to have missed my message three minutes

Re: try/catch/else

2018-02-13 Thread T.J. Crowder
On Tue, Feb 13, 2018 at 12:37 PM, Alan Plum 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 ___ es-discuss

Re: try/catch/else

2018-02-13 Thread Alan Plum
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

2018-02-13 Thread T.J. Crowder
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

2018-02-13 Thread T.J. Crowder
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

2018-02-13 Thread Alan Plum
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

2018-02-13 Thread Isiah Meadows
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

2018-02-13 Thread Alan Plum
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

2018-02-12 Thread Waldemar Horwat
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

2018-02-09 Thread Alan Plum
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

2018-02-09 Thread Augusto Moura
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

2018-02-09 Thread Claude Pache
> 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

2018-02-09 Thread Alan Plum
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

2018-02-08 Thread Peter van der Zee
>> On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache >> wrote: >>> >>> What about the following pattern (labelled block + break)? >>> >>> ```js >>> processSuggestions: { >>> let suggestions; >>> try { >>> suggestions = await fetchSuggestions(); >>> } catch

Re: try/catch/else

2018-02-08 Thread Isiah Meadows
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

2018-02-08 Thread Mark Miller
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

2018-02-08 Thread Claude Pache
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

2018-02-08 Thread Alan Plum
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

2018-02-08 Thread Michael Luder-Rosefield
Well, since promise.then(/**blah**/).catch(/**blah**/) is already a thing, why not stick with that? try { // blah } then(val) { // blah } catch { // blah } finally { // blah } I added `val` to the then since we might want to pass something from `try` to it, just as promises do. Best way to