Re: an operator for ignoring any exceptions

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

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

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. 

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

Re: an operator for ignoring any exceptions

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: Re: Array.prototype.toObjectByProperty( element=>element.property )

Of these, insertion ordering is the only one that may be compelling enough to me when I require that, to overcome the disadvantages. I never use the object prototype and I'm not convinced about the performance aspect. I reiterate though that `Map.fromIterable(allThePeople, person=>person.name)` is

Re: an operator for ignoring any exceptions

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: Re: Array.prototype.toObjectByProperty( element=>element.property )

@Alexander The idea of a generalized `map` function (etc, I’m guessing) is appealing. From the way you talked about it, it sounds like there may have been past discussion on the topic. Are there any proposals for this or major ideas being batted around? > Why? What's the advantage? You lose at

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

On Thu, Aug 10, 2017 at 11:24 PM, Alexander Jones wrote: > > As far as I'm concerned, "most data arrays" — at least the ones > you're speaking about — should actually be `Map`s. I see the point you're trying to make, but 1. I routinely want paging and other access by arbitrary