me at pluma.io (2018-02-08T15:42:54.837Z)
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 equivalent to `tryFn().then(thenFn).catch(catchFn)` which is actually just the same as the first example, not the try/catch/else. I also think having the `else` after the `catch` makes the intention clearer (just like `finally` comes after `catch` and `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 equivalent to tryFn().then(thenFn).catch(catchFn) which is actually just the same as the first example, not the try/catch/else. I also think having the else after the catch makes the intention clearer (just like finally comes after catch and else). On Thu, Feb 8, 2018, at 4:20 PM, Michael Luder-Rosefield wrote: > 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 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 <me at pluma.io> wrote: >> __ >> 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 suggestions = await fetchSuggestions(); >> showSuggestions(suggestions); >> } catch (e) { >> alert('Failed to load suggestions'); >> // Oops, we also swallow errors from showSuggestions >> } >> // now do something else >> >> Having a more fine-grained catch wouldn't necessarily help here >> because both functions might throw the same kind of error but what >> we're really interested in is discerning the *source* of the error. >> So instead some people resort to something like this:>> >> let suggestions; >> try { >> suggestions = await fetchSuggestions(); >> } catch (e) { >> alert('Failed to load suggestions'); >> return; >> } >> showSuggestions(suggestions); >> // now do something else - unless we failed to load >> >> Note how we're forced to add a return to explicitly abort the control >> flow. Unlike the change from const to let this isn't something an IDE >> would point out while refactoring, so this actually introduces >> potential for bugs. If we don't actually want to bail out completely >> this often leads to noisy status booleans (e.g. didNotThrow) or error- >> prone checks (e.g. !suggestions is a bug if the async function really >> didn't return anything).>> >> I'm not sure about other languages but Python has a solution for this >> by adding an else clause:>> >> let suggestions; >> try { >> suggestions = await fetchSuggestions(); >> } catch (e) { >> alert('Failed to load suggestions'); >> } else { >> showSuggestions(suggestions); >> } >> // now do something else >> >> The semantics are pretty straightforward: if the try block did not >> throw, the else block is executed next (before the finally block if >> any). If the try block does throw, the else block is ignored (like a >> conditional catch that doesn't match).>> >> 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). >> There is also some 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 at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180208/13f37407/attachment-0001.html>