Exception free JavaScript?

avoiding-exceptions.js

/**
 * WHY? - BECAUSE EXCEPTIONS/TRY/CATCH IS A GLOBAL HORRIBLE MESS :-(
 * Check out error handling in golang: https://blog.golang.org/error-handling-and-go
 */

/**
 * Wrap an "unsafe" promise
 */
function safePromise(promise) {
  return promise
  .then(result => [undefined, result])
  .catch(error => [error, undefined]);
}

/**
 * Wrap an "unsafe" function that might throw
 * upon execution in a function that returns
 * a promise (which is handled "safely" with safePromise)
 *
 * NOTE: This will only handle throws that
 * are done within the same execution tick,
 * and not errors that are thrown "later"
 * within the same context (no way to do that..)
 */
function safeFunction(fn) {
  return function(...args) {
    let error = undefined;
    let result = undefined;

    try {
      result = fn.apply(this, args);
    } catch (e) {
      error = e;
    }

    return safePromise(error ? Promise.reject(error) : Promise.resolve(result));
  }
}

/**
 * Example of promise returning function that rejects
 */
function getAsset(id) {
  return Promise.reject(new Error('Booo!'));
}

/**
 * Example use with async/await
 */
async function letsDoThis() {
  // Alt 1 (wrapping a promise returning function)
  const [error, result] = await safeFunction(getAsset)(10);
  // Alt 2 (wrapping a promise)
  const [error, result] = await safePromise(getAsset(10));
  
  if (error) {
    /**
     * Handle the error appropriately
     * (You could of course just throw it here if you wanted to - but it is at least optional)
     */
  }
  
  //...
}

Just some thoughts after battling with exceptions and error handling logic when orchestrating flow with async/await or function*/yield in redux-saga

Looks very similar to golang error handling :)

I use something similar.

export function safely (fn) {
  const args = arguments.length > 1 ? Array.prototype.slice.call(arguments, 1) : null
  return Promise.resolve()
    .then(!args ? fn : () => fn(...args))
    .then(result => [null, result])
    .catch(error => [error, null])
}

This replaces both safePromise and safeFunction above and also applies additional arguments if a function is given.
Example - these are all equivalent:

let [openError, file] = await safely(File.open, location)
let [openError, file] = await safely(() => File.open(location))
let [openError, file] = await safely(File.open(location))

@a-s-o nice ✌️

FWIW never pass arguments to any function other than fn.apply() if you care about performance. At least as far as V8 is concerned.

What are the advantages of coding this way? I'd love to learn more about why one would avoid exceptions/try/catch.

It's a little neater than usual try/catch, but not as good as with proper monads support.

@bstro Note that I'm not saying "don't ever use exceptions" - just that using exceptions for non-exceptional errors makes things more "global-ish", leaky and complicated. Most errors are not exceptional.

The advantage of this style (the same as in Golang) is that errors are just local values that you can deal with accordingly (or not).

Also - exceptions as a default way of handling errors doesn't really fit will into the functional programming paradigm as a first class citizen. Throwing an exception is a side-effect. Returning errors as values from a function is not (if the function is pure).

For me subjectively it is also the fact that it makes the code more convoluted (and ugly looking).

Contrived comparison:

/**
 * Example with async/await and errors as values
 * (Exceptional errors are handled on the level above)
 */
async function letsDoThis() {
  const [error, result] = await safeFunction(getAsset)('id1');
  const [otherError, otherResult] = await safePromise(getAsset('id2'));
  
  if (error || otherError) {
    // handle expected error(s)
  }

  return result || otherResult;
}

/**
 * Example with async/await using exceptions and try/catch
 * (Exceptional errors are handled on the level above)
 */
async function letsDoThis() {
  let result;
  let error;
  
  let otherResult;
  let otherError;

  try {
    // what if something exceptionally goes wrong here?
    result = await getAsset('id1');
  } catch (e) {
    error = e;
  }

  try {
    // what if something exceptionally goes wrong here?
    otherResult = await getAsset('id2');
  } catch (e) {
    otherError = e;
  }
  
  if (error || otherError) {
    /**
     * Handle the error appropriately
     * (Need to check if the error is exceptional or expected, and then re-throw the exceptional error)
     */
  }

  return result || otherResult;
}

@kirilloid - Yes, monads (Either/Maybe) is also a way of "solving" this 👍

Makes sense!

Why not use an object?

function safePromise (promise) {
  return promise
  .then(result => { result })
  .catch(error => { error })
}

// ...

const { error, result } = await safePromise(getAsset(10))

Arrays signify order, but this way you can neatly ignore the error, as opposed to doing something like const [ , result].

const { result } = await safePromise(getAsset(10))

@sscotth - You could use an object like that, but that comes with its own set of drawbacks. With an object you have to be explicit about the name of the error and result property (or whatever you choose to call it - and naming things is hard). With the array version you're really just emulating a tuple (an ordered set of values) as a way of having multiple return values, which JavaScript doesn't have as a native data structure (as opposed to golang, which does).

const [,result] = ... might be awkward, but it comes with simpler conventions / less decisions (the error comes first, the result comes second) as opposed to the object with properties (the error is called error, the result is called result)

Consider the following comparison:

// array / tuple
const [firstError, firstResult] = await safePromise(getAsset(10));
const [secondError, secondResult] = await safePromise(getAsset(20));
const [,thirdResult] = await safePromise(getAsset(30));
const [,fourthResult] = await safePromise(getAsset(40));

// vs.

// object / named parameters
const { error: firstError, result: firstResult } = await safePromise(getAsset(10));
const { error: secondError, result: secondResult } = await safePromise(getAsset(20));
const { result: thirdResult } = await safePromise(getAsset(30));
const { result: fourthResult } = await safePromise(getAsset(40));

It comes down to taste i guess, but in general I tend to prefer the solution that introduces the least amount of decisions to be made

Edit: Also - the array/tuple version forces you to be explicit about ignoring the error, which imo is a good thing ✌️

Shameless plug, I have a fork of co.js exactly for this purpose https://github.com/dg3feiko/co-nothrow

Line 52, and, Line 54 seems declare error twice?

If someone working on Node.js that concerns about performance trade-off when using try-catch then V8 recently applied turbofan optimization which is considered fixed the trade-off.

• Optimization killers

@tiansh - I'm just showing two ways of achieving the same thing ✌️️