Re: an operator for ignoring any exceptions

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

Re: an operator for ignoring any exceptions

Hikaru Nakashima
I think this idea is useful in async function.

For exsample, we write codes as below, when we use fetch()  in async function.

```js

let res, text

try {
    res = await fetch( url )
} catch ( err ) { console.log( 'network error' ) }

if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

or

```js

let res, text

res = await fetch( url ).catch( err => null )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

but, we can write as below  if we use this proposal.

```js

let res, text

res = try await fetch( url )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )

```

or do we need another syntax like "await?" ?

_______________________________________________
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

Viktor Kronvall
I think this proposal has the risk of swallowing too many errors making code hard to debug and would therefore suggest this shouldn’t be added to the language. Silent errors are hard to find the origin and cause for especially if you throw away the error message.

This might be slightly off topic but, I think we should instead wait for proper pattern matching and include a Result type similar to Scala Option or Haskell Either that is falsy in the Left error case (containing the error message) and truthy otherwise.
2017年8月11日(金) 10:17 Hikaru Nakashima <[hidden email]>:
I think this idea is useful in async function.

For exsample, we write codes as below, when we use fetch()  in async function.

```js

let res, text

try {
    res = await fetch( url )
} catch ( err ) { console.log( 'network error' ) }

if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

or

```js

let res, text

res = await fetch( url ).catch( err => null )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

but, we can write as below  if we use this proposal.

```js

let res, text

res = try await fetch( url )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )

```

or do we need another syntax like "await?" ?
_______________________________________________
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

Hikaru Nakashima
In reply to this post by Hikaru Nakashima
I have two thinkings about risk of this idea.

First, I think this syntax is almost same risk as try-catch syntax, because try-catch syntax is often used for just swallowing errors and it will be making hard to debug.
Rather, this might be better because the target of syntax is partial. This is like the techniques to convert null or undefined to basic value of types we hoped.

Second, how about make the debugger tells us silent errors like uncaught promise error.
I think we would not mind that all silent errors appear to console, because they was supposed to be appear if unless this syntax.
For above fetch example, we would want to know errors even if we want to silent it in codes. 

_______________________________________________
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

Sebastian Malton
I thought that the consensus was that pattern matching (like match in Rust) was not desirable in JS. I am pretty sure we have had a discussion about it. 

Sent: August 11, 2017 8:19 AM
Subject: Re: an operator for ignoring any exceptions

I have two thinkings about risk of this idea.

First, I think this syntax is almost same risk as try-catch syntax, because try-catch syntax is often used for just swallowing errors and it will be making hard to debug.
Rather, this might be better because the target of syntax is partial. This is like the techniques to convert null or undefined to basic value of types we hoped.

Second, how about make the debugger tells us silent errors like uncaught promise error.
I think we would not mind that all silent errors appear to console, because they was supposed to be appear if unless this syntax.
For above fetch example, we would want to know errors even if we want to silent it in codes. 

_______________________________________________
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

Michał Wadas
In reply to this post by Hikaru Nakashima
It's extremely unlikely that new syntax will be introduced to replace one line helper function. Especially after experiences of PHP where swallow-error operator is a source of eternal torment.

swallowException = fn => Promise.resolve().then(fn).catch(()=>null)

On Fri, Aug 11, 2017 at 10:16 AM, Hikaru Nakashima <[hidden email]> wrote:
I think this idea is useful in async function.

For exsample, we write codes as below, when we use fetch()  in async function.

```js

let res, text

try {
    res = await fetch( url )
} catch ( err ) { console.log( 'network error' ) }

if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

or

```js

let res, text

res = await fetch( url ).catch( err => null )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

but, we can write as below  if we use this proposal.

```js

let res, text

res = try await fetch( url )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )

```

or do we need another syntax like "await?" ?

_______________________________________________
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

Jordan Harband

On Fri, Aug 11, 2017 at 7:13 AM, Michał Wadas <[hidden email]> wrote:
It's extremely unlikely that new syntax will be introduced to replace one line helper function. Especially after experiences of PHP where swallow-error operator is a source of eternal torment.

swallowException = fn => Promise.resolve().then(fn).catch(()=>null)

On Fri, Aug 11, 2017 at 10:16 AM, Hikaru Nakashima <[hidden email]> wrote:
I think this idea is useful in async function.

For exsample, we write codes as below, when we use fetch()  in async function.

```js

let res, text

try {
    res = await fetch( url )
} catch ( err ) { console.log( 'network error' ) }

if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

or

```js

let res, text

res = await fetch( url ).catch( err => null )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )


```

but, we can write as below  if we use this proposal.

```js

let res, text

res = try await fetch( url )
if ( ! res ) console.log( 'network error' )

else if ( ! res.ok ) console.log( 'server error' ) 
else text = await res.text( )

```

or do we need another syntax like "await?" ?

_______________________________________________
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

Hikaru Nakashima
In reply to this post by Hikaru Nakashima
Mr. Wadas,
I think whether it can replace by one line helper function is not much relationship, because `Optional Chaining`, `Throw expressions`, or many proposals can replace so too.

In addition, there is `optional catch binding` proposal, and this idea is less dangerous.
Rather, this idea looks natural, because `foo = try bar` is looks like `foo = do { try { bar }  }` .

_______________________________________________
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
On Sat, Aug 12, 2017 at 7:14 AM, Hikaru Nakashima <[hidden email]> wrote:
> In addition, there is `optional catch binding` proposal, and this
> idea is less dangerous.
> Rather, this idea looks natural, because `foo = try bar` is looks
> like `foo = do { try { bar }  }` .

I think you're misunderstanding the [optional catch binding proposal][1]. It does **not** make `try { something }` valid. It makes `try { something } catch { }` valid. It's for all those times you don't need the exception, so the *binding* (the `(e)` part of `catch (e)`) is made optional.

If I'm wrong about your misunderstanding the proposal, my apologies; if so, what's dangerous about optional catch bindings?

Making `catch` optional would indeed, in my view, be dangerous, which is why I don't like the suggestion that's the topic of this thread. If you're going to ignore exceptions on a block, for which, yes, there are valid use cases, I much prefer that it be explicit.

-- 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

Hikaru Nakashima
In reply to this post by Hikaru Nakashima
I'm sorry, I was misunderstanding and confused, and thank you to teach me.

I want you to tell me why dangerous to omit `catch`.
Is that because, people abuse the syntax ?

_______________________________________________
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
On Sun, Aug 13, 2017 at 6:21 PM, Hikaru Nakashima <[hidden email]> wrote:
> I want you to tell me why dangerous to omit `catch`.
> Is that because, people abuse the syntax ?

"Dangerous" is a bit over-the-top, I was just reusing the word for parallel construction.

But I prefer explicit to implicit. This:

```js
try { something; } catch { }
```

isn't that much longer than this:

```js
try { something; }
```

...and for me, having that glaring empty block there saying "You really should do something here" is a good thing. :-)

-- 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

Claude Pache
In reply to this post by Hikaru Nakashima
Note that, in a try/catch/finally construct, you can already omit the catch clause if there is a finally clause. The effect, of course, is not to swallow the exception, but, on the contrary, to propagate it as if there was `catch (e) { throw e }`. (The useful part of such a construct is the finally clause.)

Also, in languages and dialects supporting conditional catch clauses, if the thrown exception does not match the condition of any catch clause, it is propagated.

So, the rule is: If there a matching catch clause, the exception is handled by it; otherwise, it is propagated. Reversing that rule (“propagated” → “not propagated”) is very dubious, to start (regardless of any other consideration).

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