try/catch/else

[Alan Plum]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180208/185565f5/attachment-0001.html>