Tuples/Objects and Falsy errors.

[arthurfiorette]

Additional post on twitter

As you might've seen in some issues around here. There's a discussion about the usage of [tuples] or {objects} as the result for this operator, as well as falsy errors, like throw undefined or more common cases like throw functionThatMightReturnUndefinedOrAnError().

---

Here's things that this proposal will NOT solve for you.

• This proposal does not aims to create a Result<T> like object class with unary operations like .unwrap(), .mapError(fn) and/or .orElse(data). This can be easily achievable by current JS code and I'm pretty sure there's tons of libraries like this one out there.

• This proposal will not change the behavior of any function or its return type. The safe assignment operator (or future try expression as of Discussion: Preferred operator/keyword for safe assignment #4) is to improve the caller experience and not the callee.

---

Return type syntaxes

I'll be using the chosen syntax at #4 for these examples.

Tuple:

Tuples are easier to destructure and follows the concept of error first destructuring.

Simple use case:

const [error, data] = try fn();

if (error) {
  console.error(error);
  return;
}

console.log(data);

Complex use case:

const [reqErr, response] = try await fetch('url')

if (reqErr) {
  console.error(reqErr);
  return;
}

const [parseErr, json] = try await response.json();

if (parseErr) {
  console.error(parseErr);
  return;
}

const [validateErr, validatedData] = try validate(json);

if (validateErr) {
  console.error(validateErr);
  return;
}

return validatedData;

Objects:

Simple use case:

const { error, data } = try fn();

if (error) {
  console.error(error);
  return;
}

console.log(data);

Complex use case:

const { error: reqErr, data: response } = try await fetch('url')

if (reqErr) {
  console.error(reqErr);
  return;
}

const maybeJson = try await response.json();

if (maybeJson.error) {
  console.error(maybeJson.error);
  return;
}

const { data: validatedData, error: validatedError } = try validate(maybeJson.data);

if (validatedError ) {
  console.error(validatedError );
  return;
}

return validatedData;

Both of them

An Object with error, data property and Symbol.iterator is also a valid solution.

Later we would need to improve the TS typings for that Symbol.iterator result to not mix error | data types on both destructure values, but since TS already did that for tuples ([1, 2, 3]) it won't be a problem.

Falsy values

Ideally, we should have some sort of wrapper against falsy errors, as in the end having falsy values wrapped are much helpful in such problems.

Besides intended use cases, no one expects to face a null inside a catch(error) block or neither will know how to handle that correctly.

Since errors are now treated as values, in both return types, we should have a way to differentiate them.

We have two main approaches:

helper property

Just like on Promise.allSettled's status property, we could have a .ok or something to tell the user that if the operation failed or not.

// obviously ok, could have as syntax like `fail` or a `status === 'err' || 'ok'`
const [ok, fnError, fnData] = try fn()
const { ok, error: fnError, data: fnData } = try fn()

if (!ok) {
  console.log(fnError)
}

const maybeResult = try fn()

if (!maybeResult.ok) {
  console.log(maybeResult.error)
}

Error wrapper

Wrapping the falsy value (0, '', null, ...) into a NullableError class or something could arguably be presented as a good feature of this proposal as well, where we reduce the amount or burden that these errors would mean into a more useful value.

For example, an application crashing with undefined and nothing more in the terminal is way worse than having an error like the following is much more useful in all meanings:

NullableError: Caught false error value
    at REPL20:1:1
    at ContextifyScript.runInThisContext (node:vm:136:12)
    at REPLServer.defaultEval (node:repl:598:22)
    at bound (node:domain:432:15)
    at REPLServer.runBound [as eval] (node:domain:443:12)
    at REPLServer.onLine (node:repl:927:10)
    at REPLServer.emit (node:events:531:35)
    at REPLServer.emit (node:domain:488:12)
    at [_onLine] [as _onLine] (node:internal/readline/interface:417:12)
    at [_line] [as _line] (node:internal/readline/interface:888:18) {
  value: ''
}

[crazytonyi]

Was 'falue' a typo, or is it a portmanteau of "falsy value"?

[bmeck]

I'd make a few arguments for an instance of some object type.

1. Could in the future vary the object type like AggregateError expanded Error; it is possible { error, expectedError, value } could be setup in a way to help deal with the dreaded untype catch problem in TS potentially. (either via Duck or nominal typing). Would want some input from TS team on this though to confirm.
2. Use of getter/setters from a shared prototype avoids extraneous allocation.

Even w/o TS the ability to extend Iterables (not tuples per JS spec nomenclature!) is more limited and requires iteration of all keys to get to the value desired, compare:

let foo = () => { /*...*/ ; return undefined; }
let obj ?= foo()
if (obj.threw) {
  // ...obj.error
}
let [err, value] ?= foo()
if (err) {
  // potentially was thrown for falsy values
}

Helpers for specific case detection would not really have API space in the iterator form.

[sergiohdljr]

aesthetically I prefer tuple

[crazytonyi]

aesthetically I prefer tuple

That's interesting, because I find them aesthetically unpleasant. There have been arguments throughout for why they are functionally better for this purpose, so I'm not saying they are wrong, but aesthetically, they look dumb to me. Because they assume what the operation/expression will return. It's like a fun "let's just see if this works" style of setting variables. Maybe this is part of what I find disjointed about the entire proposal, is that deconstructed assignment doesn't look stable or sensible to me (from a distance).

I'm sure they'll carve all of my personal opinions about coding on my tombstone. But as long as you bring up what we prefer aesthetically, I figured I'd chime in.

[sergiohdljr]

aesthetically I prefer tuple

That's interesting, because I find them aesthetically unpleasant. There have been arguments throughout for why they are functionally better for this purpose, so I'm not saying they are wrong, but aesthetically, they look dumb to me. Because they assume what the operation/expression will return. It's like a fun "let's just see if this works" style of setting variables. Maybe this is part of what I find disjointed about the entire proposal, is that deconstructed assignment doesn't look stable or sensible to me (from a distance).

I'm sure they'll carve all of my personal opinions about coding on my tombstone. But as long as you bring up what we prefer aesthetically, I figured I'd chime in.

i kinda see what you tryna say, but the same apply for a object, maybe your problem are with destructuring

[felippe-regazio]

I think it would be safer to use an exotic object or constructor like Error or Response due the positional nature of "tuples". I don't know... SafeOperation?

• extensible
• easily testable/mockable
• instant TS compatibility

const n: SafeOperation ?= fn();

Where:

type SafeOperation = { error, result };

Allowing:

const { error, result } ?= fn(); // SafeOperation type/constructor infered by the operator

I think an exotic object also does make sense since JS doesn't really have tuples (just another exotic object: Array) that can lead to strange behaviors (#5 (comment)). SafeOperation In the future can extend its own properties depending on the context, e.g.: Error which may have a response property in a network operation context (not the case of the context here, but just for the sake of the example. Something more appropriated would be: #6 (comment)).

Also as I mentioned, would be cool to use it like a Error or Response constructor:

const n = new SafeOperation(error, result); // constructs a new SafeOperation object which error and result properties

Or

const n = new SafeOperation(fn()); // constructs a new SafeOperation resultant of the fn();

[garretmh]

I'm drawn to the idea of wrapping non-Error thown values in a dedicated Error and returning a tuple. I think it would be a very nice way to deal with sync errors. I just can't see the TC39 committee going for it. I'm not exactly sure why but something about coercing thrown values doesn't feel JavaScript.

[khaosdoctor]

Even though I aesthetically prefer the object, I would go with tuples for a few reasons:

1. This is already a known standard (from React useState)
2. Tuples allow you to change the names of the error and data properties as you wish without the need of explicitly stating the original: { error: errObject, result: fetchResult } vs [errObject, fetchResult]

However, to @felippe-regazio's comment, I think it's also a possibility to think, either adding it as Result like Entries does for Maps and Sets, but instead of retuning the object, it returns a tuple.

[TheUniqueMathemagician]

Exactly, I also think that tuples could be a nicer option than using object destructuring because this lets people re-assign value names, thus allowing the following pattern to emerge:

const [authorsError, authors] ?= await fetch("/authors")

if (authorsError) { /* handle error */ }

const [booksError, books] ?= await fetch("/books")

if (booksError) { /* handle error */ }