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
  siegfried at ehret.me



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
> <coagmano at gmail.com> 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: coagmano at gmail.com
>> id: keybase.io/coagmano | pgp: 43B91213.asc[1]
>> 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 <kaizhu256 at gmail.com>, 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" <llltgd at 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.)>>>> 
>>>>  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 at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>> 
>>> _______________________________________________
>>>  es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>>  es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> _________________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


Links:

  1. https://keybase.io/coagmano/pgp_keys.asc?fingerprint=dab3030d5c21e5f34e17c98eba2b632843b91213
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170802/08fbe78f/attachment.html>