an operator for ignoring any exceptions

T.J. Crowder tj.crowder at
Wed Aug 2 10:45:01 UTC 2017

On Wed, Aug 2, 2017 at 4:58 AM, Sheng TIAN <llltgd at> 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 general, a thorough search before posting is your best course.

To the idea: I join the chorus saying that making it easy to ignore errors
is generally not a good idea. And reusing `try` for something that
suppresses exceptions implicitly is separately not a good idea in my view.

However, the concept of a `try-catch` expression may have some value, just
as [`throw` expressions]( may have some
value. For instance, your JSON example:

const resp = try JSON.parse(xhr.responseText) catch undefined;
There I'm incorporating the idea of [`catch` with an optional binding]( More on
that in a moment.


TryCatchExpression :
    try AssignmentExpression catch AssignmentExpression
1. Let *ref* be the result of evaluating the first *AssignmentExpression*
2. If *ref* is an abrupt completion:
 a. Let *ref* be the result of evaluating the second *AssignmentExpression*
 b. ReturnIfAbrupt(*ref*)
3. Let *val* be ! GetValue(*ref*)
3. Return *val*

...or something along those lines.

(I'm not immediately seeing a role for `finally` in such a thing.)

This would apply to various expression contexts, such as a concise arrow
function body:

doRequest().then(text => try JSON.parse(text) catch undefined).then//...

as opposed to (still incorporating optional `catch` bindings):

doRequest().then(text => { try { return JSON.parse(text); } catch { return
undefined; } }).then//...

or the more concise but less clear:

doRequest().then(text => { try { return JSON.parse(text); } catch { }

If you want a `catch` binding, such as this...probably less-than-ideal

const resp = try JSON.parse(xhr.responseText) catch (error) ({error});

...I suppose the scope of the binding could be limited to the `catch`
expression (just as the scope of the parameters to a concise arrow function
are scoped to that function's expression body; "just" without the function

 **If** a concise "use `undefined` on error" were considered a good idea,
the `catch` expression could default to `undefined` if not given (not
entirely unlike falling off the end of a function):

const resp = try JSON.parse(xhr.responseText) catch;

Personally, I prefer explicit to implicit and wouldn't want an implied

All of that said, I wonder if the gains are really worth the complexity of
syntax. But in a world where `throw` expressions and [`do` expressions]( are on
the table (to varying degrees), a `try-catch` expression may be of
interest, particularly in FP.

-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list