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
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
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
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
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
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
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,
: 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
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
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
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 =
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
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
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:
>>>
>>>>
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
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
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
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
18 matches
Mail list logo