Skip to content

Instantly share code, notes, and snippets.

@eiriklv
Last active February 2, 2019 12:13
Show Gist options
  • Save eiriklv/1fb4af8a268b394ddce5b8e4623bc546 to your computer and use it in GitHub Desktop.
Save eiriklv/1fb4af8a268b394ddce5b8e4623bc546 to your computer and use it in GitHub Desktop.
Exception free JavaScript?
/**
* 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)
*/
}
//...
}
@eiriklv
Copy link
Author

eiriklv commented Feb 3, 2017

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

@JiLiZART
Copy link

JiLiZART commented Feb 4, 2017

Looks very similar to golang error handling :)

@a-s-o
Copy link

a-s-o commented Feb 4, 2017

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))

@eiriklv
Copy link
Author

eiriklv commented Feb 4, 2017

@a-s-o nice ✌️

@mscdex
Copy link

mscdex commented Feb 4, 2017

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

@bstro
Copy link

bstro commented Feb 6, 2017

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

@kirilloid
Copy link

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

@eiriklv
Copy link
Author

eiriklv commented Feb 6, 2017

@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;
}

@eiriklv
Copy link
Author

eiriklv commented Feb 6, 2017

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

@bstro
Copy link

bstro commented Feb 6, 2017

Makes sense!

@sscotth
Copy link

sscotth commented Feb 7, 2017

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))

@eiriklv
Copy link
Author

eiriklv commented Feb 7, 2017

@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 ✌️

@dg3feiko
Copy link

dg3feiko commented Feb 9, 2017

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

@tiansh
Copy link

tiansh commented Feb 13, 2017

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

@thenewvu
Copy link

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.

@eiriklv
Copy link
Author

eiriklv commented Feb 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment