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
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
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,
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
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
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`
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
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:
>
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) {...}
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.
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) {
> 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
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:
>> 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
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
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
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);
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
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
19 matches
Mail list logo