an operator for ignoring any exceptions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

an operator for ignoring any exceptions

. 田生
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.)

For example, we may introduce an unary operator called `try` which

1. calculate the operand first
2. if it not throw, return as is
3. otherwise return undefined

This operator may be used when exceptions should always be ignored.

Example:

    let resp;
    try {
      resp = JSON.parse(xhr.responseText);
    } catch (_ignore) { /* do nothing here */ }

may be simplified to:

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

Another Example:

    var age = user && user.age;

to:

    var age = try user.age;

(Note, in such case, if operand is start with curly braces "{", it must be wrapped in parentheses "()".)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: an operator for ignoring any exceptions

kai zhu

-1
in my real-world experience, JSON.parse and nodejs fs.readFileSync are the only 2 common use-cases that would benefit from this.  its more practical to use helper-functions for those 2 use-cases rather than change the javascript language yet again (besides, returning an empty string is commonly more useful for me than returning undefined for failed fs.readFileSync).

this is also a likely footgun that would get abused by novice programmers for many inappropriate use-cases.

On Aug 2, 2017 11:59 AM, "Sheng TIAN" <[hidden email]> 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.)

For example, we may introduce an unary operator called `try` which

1. calculate the operand first
2. if it not throw, return as is
3. otherwise return undefined

This operator may be used when exceptions should always be ignored.

Example:

    let resp;
    try {
      resp = JSON.parse(xhr.responseText);
    } catch (_ignore) { /* do nothing here */ }

may be simplified to:

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

Another Example:

    var age = user && user.age;

to:

    var age = try user.age;

(Note, in such case, if operand is start with curly braces "{", it must be wrapped in parentheses "()".)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: an operator for ignoring any exceptions

Frederick Stark
Having recently inherited a codebase which silently consumes errors in many places (using try/catch, Promises that don't reject - just stall, and promise.catch noops), I can imagine these getting used terribly.

At least with the current operators, there's an expectation in the syntax that you will handle the error, and you have to make the conscious decision to ignore the error. Introducing an operator that does it for you implies to novice programmers that it's an okay thing to do.

The amount of extra code required to ignore the errors is not very onerous, and if you need it frequently, you can always put it in a wrapper function.

--
Fred Stark
m: 0468 828 420 | e: [hidden email]

I acknowledge the Gadigal people of the Eora Nation, who are the traditional owners of the land on which I work and live.


On 2 Aug 2017, 2:30 PM +1000, kai zhu <[hidden email]>, wrote:

-1
in my real-world experience, JSON.parse and nodejs fs.readFileSync are the only 2 common use-cases that would benefit from this.  its more practical to use helper-functions for those 2 use-cases rather than change the javascript language yet again (besides, returning an empty string is commonly more useful for me than returning undefined for failed fs.readFileSync).

this is also a likely footgun that would get abused by novice programmers for many inappropriate use-cases.

On Aug 2, 2017 11:59 AM, "Sheng TIAN" <[hidden email]> 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.)

For example, we may introduce an unary operator called `try` which

1. calculate the operand first
2. if it not throw, return as is
3. otherwise return undefined

This operator may be used when exceptions should always be ignored.

Example:

    let resp;
    try {
      resp = JSON.parse(xhr.responseText);
    } catch (_ignore) { /* do nothing here */ }

may be simplified to:

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

Another Example:

    var age = user && user.age;

to:

    var age = try user.age;

(Note, in such case, if operand is start with curly braces "{", it must be wrapped in parentheses "()".)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: an operator for ignoring any exceptions

Naveen Chawla
Yes I wouldn't remove the "catch" feature. However the idea of a "ternary" like operator expression for `try` `catch` and `finally` might be interesting, e.g.:

```javascript
const resp = try? JSON.parse(xhr.responseText) catch(e): 'Error: '+e.message finally: console.log('done!');  
```

On Wed, 2 Aug 2017 at 10:45 Frederick Stark <[hidden email]> wrote:
Having recently inherited a codebase which silently consumes errors in many places (using try/catch, Promises that don't reject - just stall, and promise.catch noops), I can imagine these getting used terribly.

At least with the current operators, there's an expectation in the syntax that you will handle the error, and you have to make the conscious decision to ignore the error. Introducing an operator that does it for you implies to novice programmers that it's an okay thing to do.

The amount of extra code required to ignore the errors is not very onerous, and if you need it frequently, you can always put it in a wrapper function.

--
Fred Stark
m: 0468 828 420 | e: [hidden email]

I acknowledge the Gadigal people of the Eora Nation, who are the traditional owners of the land on which I work and live.


On 2 Aug 2017, 2:30 PM +1000, kai zhu <[hidden email]>, wrote:

-1
in my real-world experience, JSON.parse and nodejs fs.readFileSync are the only 2 common use-cases that would benefit from this.  its more practical to use helper-functions for those 2 use-cases rather than change the javascript language yet again (besides, returning an empty string is commonly more useful for me than returning undefined for failed fs.readFileSync).

this is also a likely footgun that would get abused by novice programmers for many inappropriate use-cases.

On Aug 2, 2017 11:59 AM, "Sheng TIAN" <[hidden email]> 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.)

For example, we may introduce an unary operator called `try` which

1. calculate the operand first
2. if it not throw, return as is
3. otherwise return undefined

This operator may be used when exceptions should always be ignored.

Example:

    let resp;
    try {
      resp = JSON.parse(xhr.responseText);
    } catch (_ignore) { /* do nothing here */ }

may be simplified to:

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

Another Example:

    var age = user && user.age;

to:

    var age = try user.age;

(Note, in such case, if operand is start with curly braces "{", it must be wrapped in parentheses "()".)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: an operator for ignoring any exceptions

Siegfried Ehret
Hello,

This proposal approach the same subject: https://github.com/michaelficarra/optional-catch-binding-proposal/ (stage 3)

Not handling errors is a bad practice.
I join Kai Zhu and Frederick Stark here, this should not be a language feature.

--
  Siegfried Ehret



On Wed, Aug 2, 2017, at 08:30 AM, Naveen Chawla wrote:
Yes I wouldn't remove the "catch" feature. However the idea of a "ternary" like operator expression for `try` `catch` and `finally` might be interesting, e.g.:

```javascript
const resp = try? JSON.parse(xhr.responseText) catch(e): 'Error: '+e.message finally: console.log('done!');  
```

On Wed, 2 Aug 2017 at 10:45 Frederick Stark <[hidden email]> wrote:
Having recently inherited a codebase which silently consumes errors in many places (using try/catch, Promises that don't reject - just stall, and promise.catch noops), I can imagine these getting used terribly.

At least with the current operators, there's an expectation in the syntax that you will handle the error, and you have to make the conscious decision to ignore the error. Introducing an operator that does it for you implies to novice programmers that it's an okay thing to do.

The amount of extra code required to ignore the errors is not very onerous, and if you need it frequently, you can always put it in a wrapper function.

--
Fred Stark
m: 0468 828 420 | e: [hidden email]

I acknowledge the Gadigal people of the Eora Nation, who are the traditional owners of the land on which I work and live.


On 2 Aug 2017, 2:30 PM +1000, kai zhu <[hidden email]>, wrote:

-1
in my real-world experience, JSON.parse and nodejs fs.readFileSync are the only 2 common use-cases that would benefit from this.  its more practical to use helper-functions for those 2 use-cases rather than change the javascript language yet again (besides, returning an empty string is commonly more useful for me than returning undefined for failed fs.readFileSync).

this is also a likely footgun that would get abused by novice programmers for many inappropriate use-cases.

On Aug 2, 2017 11:59 AM, "Sheng TIAN" <[hidden email]> 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.)

For example, we may introduce an unary operator called `try` which

1. calculate the operand first
2. if it not throw, return as is
3. otherwise return undefined

This operator may be used when exceptions should always be ignored.

Example:

    let resp;
    try {
      resp = JSON.parse(xhr.responseText);
    } catch (_ignore) { /* do nothing here */ }

may be simplified to:

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

Another Example:

    var age = user && user.age;

to:

    var age = try user.age;

(Note, in such case, if operand is start withcurly braces "{", it must be wrapped in parentheses "()".)

_______________________________________________
es-discuss mailing list

_______________________________________________
es-discuss mailing list
_______________________________________________
es-discuss mailing list
_______________________________________________
es-discuss mailing list


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: an operator for ignoring any exceptions

T.J. Crowder-2
In reply to this post by . 田生
On Wed, Aug 2, 2017 at 4:58 AM, Sheng TIAN <[hidden email]> 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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: an operator for ignoring any exceptions

Tab Atkins Jr.
On Wed, Aug 2, 2017 at 3:45 AM, T.J. Crowder
<[hidden email]> wrote:

> On Wed, Aug 2, 2017 at 4:58 AM, Sheng TIAN <[hidden email]> 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.

Agree. Note that the similar operator (`try!(...)`) in Rust does not
*suppress* errors, but rather just simplifies handling of the error
(in Rust, expressed using a Result object); if an error is returned it
immediately returns from the outer function with the Result object;
otherwise it evaluates to the (unwrapped from the Result object)
success value.  This is closer to the try expression you bring up,
just with some slightly more opinionated handling.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss