There was a good bit of buzz today about the new proposal for a safe assignment operator (?=) in JavaScript. I love how JavaScript has improved over time, but this is also a problem I've run into in a few cases lately. I should whip up a quick example implementation as a function, right?

In case you haven't read the proposal, here's what it proposes:

const [error, value] ?= maybeThrows();

The new ?= operator would be equivalent to calling the right side of the assignment in a try/catch block, returning an array. The first value of the returned array would be an error if something threw inside the assignment, and the second value would be the result of the assignment if nothing threw.

A Common try/catch Annoyance

I frequently bump into code that feels pretty ugly around assignment and try/catch blocks. Things like this:

let errorMsg;

try {
  maybeThrow();
} catch (e) {
  errorMsg = "An error message";
}

To access errorMsg outside of the try/catch block using const or let you have to define it outside of the block.

A Non-Async Implementation

The easiest case here is handling non-async functions. I was able to whip up
some test cases and a function called tryCatch in no time:

function tryCatch(fn, ...args) {
  try {
    return [undefined, fn.apply(null, args)]
  } catch (e) {
    return [e, undefined];
  }
}

function throws() {
  throw new Error("It threw");
}

// returns a sum
// prints [ undefined, 2 ]
console.log(tryCatch(Math.sqrt, 4));

// returns an error
// prints [ Error: 'It threw', undefined ]
console.log(tryCatch(throws));

tryCatch calls the function with the given arguments wrapped in a try/catch block. It appropriately returns [undefined, result] if nothing throws inside the function, and [error, undefined] if something does throw.

Note that you can use an anonymous function with tryCatch as well if you don't already have a function ready to call.

console.log(tryCatch(() => {
  throw new Error("It threw");
}));

Handling Async Functions

Async functions get a little trickier. One idea I initially had was to write
a completely async version, maybe called asyncTryCatch, but where's the challenge in that. This is a completely pointless exploration! Here's an implementation of tryCatch that works with both async and non-async functions:

function tryCatch(fn, ...args) {
  try {
    const result = fn.apply(null, args);

    if (result.then) {
      return new Promise(resolve => {
          result
            .then(v => resolve([undefined, v]))
            .catch(e => resolve([e, undefined]))  
      }); 
    }

    return [undefined, result];
  } catch (e) {
    return [e, undefined];
  }
}

function throws() {
  throw new Error("It threw");
}

async function asyncSum(first, second) {
  return first + second;
}

async function asyncThrows() {
  throw new Error("It throws async");
}

// returns a sum
// prints [ undefined, 2 ]
console.log(tryCatch(Math.sqrt, 4));

// returns an error
// prints [ Error: 'It threw', undefined ]
console.log(tryCatch(throws));

// returns a promise resolving to value
// prints [ undefined, 3 ]
console.log(await tryCatch(asyncSum, 1, 2));

// returns a promise resolving to error
// prints [ Error: 'It throws async', undefined ]
console.log(await tryCatch(asyncThrows));

It looks a lot like the original version, but with some Promise based code
thrown in for good measure. With this implementation you can call tryCatch when calling a non-async function, and then call await tryCatch when calling an async function.

Let's look at the Promise bit:

if (result.then) {
  return new Promise(resolve => {
      result
        .then(v => resolve([undefined, v]))
        .catch(e => resolve([e, undefined]))    
  }); 
}

if (result.then) checks if the given function (called with apply) returned a Promise. If it did, we need to return a Promise ourselves.

Calling result.then(v => resolve([undefined, v])) causes the promise to resolve to the value the given function returned, if nothing throws.

.catch(e => resolve([e, undefined])) is a little trickier. I originally wrote
it as .catch(e => reject([e, undefined])), but that causes an uncaught error
to fall out of tryCatch. We need to resolve here because we're returning an
array, not throwing an error.

And Finally

I pretty regularly have cases where I need to try/catch but feel like the
explicit try/catch block takes up a ton of space and is annoying for scoping assignments. I'm not sure if I'll use it or not, but this was a fun little exploration.