Re: an operator for ignoring any exceptions

2017-08-14 Thread Claude Pache
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

Re: an operator for ignoring any exceptions

2017-08-13 Thread T.J. Crowder
On Sun, Aug 13, 2017 at 6:21 PM, Hikaru Nakashima 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

Re: an operator for ignoring any exceptions

2017-08-13 Thread 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 es-discuss@mozilla.org

Re: an operator for ignoring any exceptions

2017-08-12 Thread T.J. Crowder
On Sat, Aug 12, 2017 at 7:14 AM, Hikaru Nakashima 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

Re: an operator for ignoring any exceptions

2017-08-12 Thread 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

Re: an operator for ignoring any exceptions

2017-08-11 Thread Jordan Harband
Relevant existing proposals: - https://github.com/tc39/proposal-optional-catch-binding/ - https://github.com/tc39/proposal-pattern-matching/ On Fri, Aug 11, 2017 at 7:13 AM, Michał Wadas wrote: > It's extremely unlikely that new syntax will be introduced to replace

Re: an operator for ignoring any exceptions

2017-08-11 Thread Michał Wadas
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,

Re: an operator for ignoring any exceptions

2017-08-11 Thread Sebastian Malton
: 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

Re: an operator for ignoring any exceptions

2017-08-11 Thread 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

Re: an operator for ignoring any exceptions

2017-08-11 Thread 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

Re: an operator for ignoring any exceptions

2017-08-11 Thread 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 =

Re: an operator for ignoring any exceptions

2017-08-02 Thread Tab Atkins Jr.
On Wed, Aug 2, 2017 at 3:45 AM, T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: > On Wed, Aug 2, 2017 at 4:58 AM, Sheng TIAN <lll...@gmail.com> wrote: >> Is there any proposal for an one unary operator for ignoring any >> exceptions. >> >> (I

Re: an operator for ignoring any exceptions

2017-08-02 Thread T.J. Crowder
On Wed, Aug 2, 2017 at 4:58 AM, Sheng TIAN <lll...@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 gener

Re: an operator for ignoring any exceptions

2017-08-02 Thread Siegfried Ehret
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" <lll...@gmail.com> wrote: >>> >>>>

Re: an operator for ignoring any exceptions

2017-08-02 Thread Naveen Chawla
t 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:5

Re: an operator for ignoring any exceptions

2017-08-01 Thread Frederick Stark
2, 2017 11:59 AM, "Sheng TIAN" <lll...@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 > > > wonderin

Re: an operator for ignoring any exceptions

2017-08-01 Thread kai zhu
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 f

an operator for ignoring any exceptions

2017-08-01 Thread Sheng TIAN
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