On Wed, Aug 2, 2017 at 4:58 AM, Sheng TIAN <llltgd at gmail.com> wrote:
> Is there any proposal for an one unary operator for ignoring any
> exceptions.
>
> (I have not search out any related threads. But it is useful IMO,
> so I'm wondering if this had been discussed.)

In general, a thorough search before posting is your best course.

To the idea: I join the chorus saying that making it easy to ignore errors
is generally not a good idea. And reusing `try` for something that
suppresses exceptions implicitly is separately not a good idea in my view.

However, the concept of a `try-catch` expression may have some value, just
as [`throw` expressions](
https://github.com/rbuckton/proposal-throw-expressions) may have some
value. For instance, your JSON example:

```js
const resp = try JSON.parse(xhr.responseText) catch undefined;
```
There I'm incorporating the idea of [`catch` with an optional binding](
https://michaelficarra.github.io/optional-catch-binding-proposal/). More on
that in a moment.

E.g.:

**Evaluation:**
```
TryCatchExpression :
    try AssignmentExpression catch AssignmentExpression
```
1. Let *ref* be the result of evaluating the first *AssignmentExpression*
2. If *ref* is an abrupt completion:
 a. Let *ref* be the result of evaluating the second *AssignmentExpression*
 b. ReturnIfAbrupt(*ref*)
3. Let *val* be ! GetValue(*ref*)
3. Return *val*

...or something along those lines.

(I'm not immediately seeing a role for `finally` in such a thing.)

This would apply to various expression contexts, such as a concise arrow
function body:

```js
doRequest().then(text => try JSON.parse(text) catch undefined).then//...
```

as opposed to (still incorporating optional `catch` bindings):

```js
doRequest().then(text => { try { return JSON.parse(text); } catch { return
undefined; } }).then//...
```

or the more concise but less clear:

```js
doRequest().then(text => { try { return JSON.parse(text); } catch { }
}).then//...
```

If you want a `catch` binding, such as this...probably less-than-ideal
example:

```js
const resp = try JSON.parse(xhr.responseText) catch (error) ({error});
```

...I suppose the scope of the binding could be limited to the `catch`
expression (just as the scope of the parameters to a concise arrow function
are scoped to that function's expression body; "just" without the function
boundary).

 **If** a concise "use `undefined` on error" were considered a good idea,
the `catch` expression could default to `undefined` if not given (not
entirely unlike falling off the end of a function):

```js
const resp = try JSON.parse(xhr.responseText) catch;
```

Personally, I prefer explicit to implicit and wouldn't want an implied
`undefined`.

All of that said, I wonder if the gains are really worth the complexity of
syntax. But in a world where `throw` expressions and [`do` expressions](
https://gist.github.com/dherman/1c97dfb25179fa34a41b5fff040f9879) are on
the table (to varying degrees), a `try-catch` expression may be of
interest, particularly in FP.

-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170802/32a12827/attachment-0001.html>

On Wed, Aug 2, 2017 at 4:58 AM, Sheng TIAN <llltgd at gmail.com> wrote:
> Is there any proposal for an one unary operator for ignoring any
> exceptions.
>
> (I have not search out any related threads. But it is useful IMO,
> so I'm wondering if this had been discussed.)

In general, a thorough search before posting is your best course.

To the idea: I join the chorus saying that making it easy to ignore errors
is generally not a good idea. And reusing `try` for something that
suppresses exceptions implicitly is separately not a good idea in my view.

However, the concept of a `try-catch` expression may have some value, just
as [`throw` expressions](
https://github.com/rbuckton/proposal-throw-expressions) may have some
value. For instance, your JSON example:

```js
const resp = try JSON.parse(xhr.responseText) catch undefined;
```
There I'm incorporating the idea of [`catch` with an optional binding](
https://michaelficarra.github.io/optional-catch-binding-proposal/). More on
that in a moment.

E.g.:

**Evaluation:**
```
TryCatchExpression :
    try AssignmentExpression catch AssignmentExpression
```
1. Let *ref* be the result of evaluating the first *AssignmentExpression*
2. If *ref* is an abrupt completion:

    a. Let *ref* be the result of evaluating the second *AssignmentExpression*

    b. ReturnIfAbrupt(*ref*)

3. Let *val* be ! GetValue(*ref*)
3. Return *val*

...or something along those lines.

(I'm not immediately seeing a role for `finally` in such a thing.)

This would apply to various expression contexts, such as a concise arrow
function body:

```js
doRequest().then(text => try JSON.parse(text) catch undefined).then//...
```

as opposed to (still incorporating optional `catch` bindings):

```js
doRequest().then(text => { try { return JSON.parse(text); } catch { return

undefined; } }).then//...
```

or the more concise but less clear:

```js
doRequest().then(text => { try { return JSON.parse(text); } catch { }
}).then//...
```

If you want a `catch` binding, such as this...probably less-than-ideal
example:

```js
const resp = try JSON.parse(xhr.responseText) catch (error) ({error});
```

...I suppose the scope of the binding could be limited to the `catch`
expression (just as the scope of the parameters to a concise arrow function
are scoped to that function's expression body; "just" without the function
boundary).

 **If** a concise "use `undefined` on error" were considered a good idea,
the `catch` expression could default to `undefined` if not given (not
entirely unlike falling off the end of a function):

```js
const resp = try JSON.parse(xhr.responseText) catch;
```

Personally, I prefer explicit to implicit and wouldn't want an implied
`undefined`.

All of that said, I wonder if the gains are really worth the complexity of
syntax. But in a world where `throw` expressions and [`do` expressions](
https://gist.github.com/dherman/1c97dfb25179fa34a41b5fff040f9879) are on
the table (to varying degrees), a `try-catch` expression may be of
interest, particularly in FP.

-- T.J. Crowder