these are statements, not expressions

[ljharb]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Versions

https://github.com/arthurfiorette/proposal-try-expressions?tab=readme-ov-file#rules-for-try-expressions item 1 says they can't be inlined, like return or throw - that makes them statements. If they were expressions, they'd be usable in any context expressions are.

A minimal reproducible example

n/a

Description

n/a

Steps to Reproduce

n/a

Expected Behavior

n/a

[arthurfiorette]

You're right! I guess i'm renaming this once again to try-statements :0

[ljharb]

Why not let them be expressions, though?

[arthurfiorette]

Their usage don't make sense.

const result = try throw new Error()
// why not just:
const error = new Error()

const result = try using x = something()
// This might make sense to catch a possible error 
// of something() throwing before returning a resource
// but wouldn't handle any resource disposal thrown error.

...

---

How would this resolve into a Result?

const result = try {
  statementOne();
  statementTwo();
}

the above is more related to proposal-do-expressions than to what this aims to solve. Once it's approved we will be able to use it like:

const result = try do {
  work()
}

Since do will evaluate into an expression and try works with expressions.

[ljharb]

because the usage wouldn't ever be try throw new Error(), it'd be try somethingThatMightThrow().

[arthurfiorette]

I think we are saying the same thing: Try is a statement that is followed by an expression. try something() is valid usage.

https://github.com/arthurfiorette/proposal-try-statements?tab=readme-ov-file#void-operations

[ljharb]

I'm suggesting that try <expression> itself be an expression - there's no reason I can see for it not to be.

[DScheglov]

The main difference between a statement and an expression is that an expression represents a value that can be used in other expressions and statements, whereas a statement does not.

A statement performs a side effect or imperatively alters the flow of execution and may return a value from the function scope (e.g., if, for, etc.). For example, try { } catch { } is a statement.

If a proposal defines try as a statement, we cannot do the following:

const x = try fn();

Conversely, if we can write this, then try fn() must be an expression.

I also see no reason why try couldn't be inlined.

I'd like to point that we cannot do something like that:

const y = while(x < 9) x++;

[DScheglov]

@arthurfiorette

const error = try throw new Error('Some Error');

must be treated as a syntax error because throw is not an expression yet.

Actually, according to the desugaring the try throw new ... is equivalent to

let _result;
try {
  _result = Result.ok(throw new Error('Some Error');
} catch(err) {
  _result = Result.error(error);
}
const result = _result;

But it is not allowed by JS, because throw is a statement.

[DScheglov]

It seems I got the initial concern to avoid inlining.

@arthurfiorette , could you please correct me if I am wrong here.

Let's consider the following case:

const result = condition
  ? try doSomething()
  : Result.ok(10);

Current desugaring with try { ... } catch () { ... } cannot cover this case correctly.

So we need to consider replacing desugaring with IEFE, but it will require different desugarring for try <expr> and try await <expr>:

The example above could be desugarred to:

const result = condition
  ? (() => { try { return Result.ok(doSomething()); } catch (error) { return Result.error(error); } })() 
  : Result.ok(10)

Note: We need to use exactly arrow function expression to keep this context untouched

The async case:

const result = condition
  ? try await doSomething()
  : Result.ok(10);

could be desugarred into:

const result = condition
  ? await (() => {
      try {
        const _r = doSomething();
        return isPromiseLike(_r) ? _r.then(Result.ok, Result.error) : Result.ok(_r);
      } catch (error) {
        return Result.error(error);
      }
    })()
  : Result.ok(10);

So, @ljharb, @arthurfiorette what do you think should we update desugaring approach?

[ljharb]

const result = condition
  ? try doSomething()
  : Result.ok(10);

would be more like:

let _result;
if (condition) {
  try {
    _result = Result.ok(doSomething());
  } catch (e) {
    _result = Result.error(e);
  }
} else {
  _result = Result.ok(10);
}
const result = _result;

there shouldn't need to be any new function scopes involved.

[DScheglov]

@ljharb

Your approach does actually mean, that inlining is not possible, and each case of try <expr> must be considered separately.

For example:

const result = value || try doSomething(); // or the same with &&

const result = fn?.(try doSomething());

[ljharb]

ah, true, there will definitely be some situations where my approach won't work.

Either way tho, inlining is possible regardless - we're talking about the transpilation/desugaring, which isn't part of the proposal.

[DScheglov]

we're talking about the transpilation/desugaring, which isn't part of the proposal.

Exactly )

By the way, what do you think about the following proposal: consider Result.error() as false value, to get able to write something like that:

const result = (try doFirst()) || (try doSecond());

(Sorry, for offtop)

[ljharb]

It's not possible to have a falsy object.

[DScheglov]

I know ) ... But we can just propose )))

Actually, we can consider something like Result static methods: Result.firstOk(...), Result.firstError() and Result.collect():

{
  const result = Result.firstOk(
    try doSomething(),
    try doSomethingElse(),
  ); // returns result of doSomething if it's ok is true, otherwise returns result of doSomethingElse
}

{
  const result = Result.firstError(
    try doSomething(),
    try doSomethingElse(),
  ); // returns result of doSomething if it's ok is false, otherwise returns result of doSomethingElse
}

{
  const results = Result.collect(
    try doSomething(),
    try doSomethingElse(),
  ); // returns Result that value is an array of successful results, and the first error met
}