DEV Community

Callback hell OR try catch hell (tower of terror)

Muhammad Ovi on June 18, 2021

What are "Callbacks"? A callback function is usually used as a parameter to another function. The function that receives callback funct...

Read full post

Spyros Argalias • Jun 19 '21

I agree. Also, if your next function happens to depend on results from the previous function, you can chain them without nesting:

function getAreas() {}
function getTowns(areas) {}
function getCities(towns) {}
function getCountries(cities) {}

getAreas()
  .then(getTowns)
  .then(getCities)
  .catch(handleError);

// or inline
getAreas()
  .then(function getTowns(areas) {})
  .then(function getCities(towns) {})
  .then(function getCountries(cities) {})
  .catch(function handleError() {});

Nice article overall though, keep it up :).

Muhammad Ovi • Jun 19 '21

Yes, this would be a good approach too :)

Aleksei Berezkin • Jun 19 '21

You can have one catch clause below all awaits

Muhammad Ovi • Jun 19 '21

But what if we have all the promise dependend on promise above them, and we want to handle error for each of them?

peerreynders • Jun 19 '21 • Edited

async function tryAll(promises, name) {
  const resolved = [];
  const rejected = [];
  // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled
  const all = await Promise.allSettled(promises);
  for (const outcome of all)
    if (outcome.hasOwnProperty('value')) resolved.push(outcome.value);
    else rejected.push(outcome.reason);

  if (rejected.length < 1) return resolved;

  const error = new Error('tryAll encountered errors');
  error.name = name;
  error.rejected = rejected;
  throw error;
}

const ERROR_NAME_MULTI_REJECT = 'ErrorMultiReject';

function handleMultiReject(multiError) {
  for (const err of multiError.rejected)
    console.log('Multi Error', err.toString());
}

function routeError(err) {
  if (err.name === ERROR_NAME_MULTI_REJECT) handleMultiReject(err);
  else console.log('Other Error -', err.toString());
}

function makeError(source, name) {
  const error = new Error(`Error from ${source}`);
  error.name = name;
  return error;
}

const testFn = (result, source, name) =>
  result ? Promise.resolve(result) : Promise.reject(makeError(source, name));

async function main() {
  try {
    const one = await testFn('one', `testFnOne`, 'ErrorOne');
    const results = await tryAll(
      [
        testFn(null, `testFnTwo`, 'ErrorTwo'),
        testFn(null, `testFnThree`, 'ErrorThree'),
        testFn('four', `testFnFour`, 'ErrorFour'),
      ],
      ERROR_NAME_MULTI_REJECT
    );
    console.log('done');
  } catch (err) {
    routeError(err);
  }
}

main();
// "Multi Error", "ErrorTwo: Error from testFnTwo"
// "Multi Error", "ErrorThree: Error from testFnThree"

Perhaps you meant something else - in which case chaining the error handlers may be worth considering:

// wrap the error with one that is uniquely named ...
async function wrapError(promise, name) {
  try {
    // https://jakearchibald.com/2017/await-vs-return-vs-return-await/#return-awaiting
    return await promise;
  } catch (err) {
    const error = new Error('Wrapped Error');
    error.name = name;
    error.wrapped = err;
    throw error;
  }
}

function makeChainedHandler(next, handler) {
  return next
    ? (err) => {
        handler(err);
        next(null);
      }
    : handler;
}

// ... so that the appropriate error handler
// to process the wrapped error can be retrieved
// which calls any other chained "aborted" handlers.  
//
function handleError(err) {
  if (err.hasOwnProperty('wrapped')) {
    const handler = handlers.get(err.name);
    if (handler) {
      handler(err.wrapped);
      return;
    }

    err = err.wrapped;
  }

  console.log('Other Error -', err.toString());
}

async function main() {
  try {
    const one = await wrapError(demoFnOne('one'), ERROR_NAME_ONE);
    const two = await wrapError(demoFnTwo(null), ERROR_NAME_TWO);
    const three = await wrapError(demoFnThree('three'), ERROR_NAME_THREE);
    const four = await wrapError(demoFnFour('four'), ERROR_NAME_FOUR);
    console.log('done');
  } catch (err) {
    handleError(err);
  }
}

// --- Begin Demo Support
const DEMO_ONE = 'DemoFnOne';
const DEMO_TWO = 'DemoFnTwo';
const DEMO_THREE = 'DemoFnThree';
const DEMO_FOUR = 'DemoFnFour';

const ERROR_NAME_ONE = 'ErrorOne';
const ERROR_NAME_TWO = 'ErrorTwo';
const ERROR_NAME_THREE = 'ErrorThree';
const ERROR_NAME_FOUR = 'ErrorFour';

const config = [
  [DEMO_ONE, ERROR_NAME_ONE],
  [DEMO_TWO, ERROR_NAME_TWO],
  [DEMO_THREE, ERROR_NAME_THREE],
  [DEMO_FOUR, ERROR_NAME_FOUR],
];

function makeError(fnName) {
  const error = new Error(`Error from ${fnName}`);
  error.name = 'Error' + fnName[0].toUpperCase() + fnName.slice(1);
  return error;
}

const makeDemoFn = (fnName) => (result) =>
  result ? Promise.resolve(result) : Promise.reject(makeError(fnName));

function makeErrorHandler(fnName) {
  return (err) => {
    if (err) {
      console.log(err.toString());
      return;
    }

    console.log(`Error: ${fnName} was aborted.`);
  };
}

function makeBoth([fnName, errName]) {
  const fn = makeDemoFn(fnName);
  const handler = makeErrorHandler(fnName);
  return [
    [fnName, fn],
    [errName, handler],
  ];
}

const [fns, handlers] = (() => {
  const fnEntries = [];
  const handlerEntries = [];
  let chained = null;

  // in reverse to set up the necessary abort chaining
  for (let i = config.length - 1; i >= 0; i -= 1) {
    const [fnEntry, [name, handler]] = makeBoth(config[i]);
    chained = makeChainedHandler(chained, handler);
    fnEntries.push(fnEntry);
    handlerEntries.push([name, chained]);
  }

  return [new Map(fnEntries), new Map(handlerEntries)];
})();

const demoFnOne = fns.get(DEMO_ONE);
const demoFnTwo = fns.get(DEMO_TWO);
const demoFnThree = fns.get(DEMO_THREE);
const demoFnFour = fns.get(DEMO_FOUR);

// --- End Demo Support

main();

// "ErrorDemoFnTwo: Error from DemoFnTwo"
// "Error: DemoFnThree was aborted."
// "Error: DemoFnFour was aborted."

peerreynders • Jun 22 '21

Your main function would look something like this

The thing is if you present code written in the manner described you have to expect to raise some eyebrows because you are ignoring error codes. Obviously you felt the need to do this - however work arounds like this are symptomatic of poor error design.

Defensive programming is messy

So messy in fact that the designers of Erlang invented "Let it Crash" (Programming Erlang 2e, p.88):

Many languages say you should use defensive programming and check the arguments to all functions. In Erlang, defensive programming is built-in. You should describe the behavior of functions only for valid input arguments; all other arguments will cause internal errors that are automatically detected. You should never return values when a function is called with invalid arguments. You should always raise an exception. This rule is called “Let it crash.”

However most runtimes don't have the luxury of letting the process die and having the supervisor deal with the crash (p.199):

If this process dies, we might be in deep trouble since no other process can help. For this reason, sequential languages have concentrated on the prevention of failure and an emphasis on defensive programming.

However there is another point to be made - not all errors are equal. Roughly speaking:

Expected errors. Errors will occur routinely during the operation of the software and therefore should be handled appropriately.
Exceptional errors. Errors that indicate that fundamental assumptions about the software and the environment that it is operating in have been violated. These type of errors cannot be handled at the local scope, so local processing is terminated and the error is passed upwards repeatedly until some kind of sensible compensating action can be taken.

Not all languages have exceptions but they have idioms for exceptional errors. Golang:

    // some processing
    result, err := doSomething()
    if err != nil {
        return err
    }

    // more processing ...

Rust has the error propagation ? operator.

  let mut f = File::open("username.txt")?;

i.e. for Ok(value) the value is is bound to the variable while an Error(error) is returned right then and there.

When a language like JavaScript supports exceptions the rule of thumb tends to be:

Use error values for expected errors.
Use exceptions for unexpected, exceptional errors.

So when we see

const [areas, areasErr] = await getAreas();

areasErr is an expected error and should be handled, not ignored. And just because an error code is returned doesn't necessarily imply that getAreas() can't be a source of unexpected errors. When we see

const areas  = await getAreas();

the code is implying that there aren't any expected errors to be handled locally but getAreas() can still be a source of unexpected errors.

With this in mind - 4.1.3. Rejections must be used for exceptional situations:

Bad uses of rejections include: When a value is asked for asynchronously and is not found.

i.e. a promise should resolve to an error value for expected errors rather than rejecting with the expected error. So when we see

const [areas, areasErr] = await promiseResolver(getAreas);

there is a bit of a code smell because all errors deemed by getAreas() as exceptional are converted to expected errors at the call site and then are promptly ignored. There is an impedance mismatch between how getAreas() categorizes certain errors and how the code using it treats them. If you have no control over getAreas() then an explicit anti-corruption function (or an entire module for a "layer") may be called for to reorganize the error categorization (and the associated semantics), e.g. :

function myGetAreas() {
  try {
    return await getAreas();
  } catch (err) {
    if (ERROR_NO_ACTION_NAMES.includes(err.name)) return [];
    else throw err;
  }
}

so that the consuming code can be plainly

const areas = await myGetAreas();

Compared to the above

const [areas, _areasErr] = await promiseResolver(getAreas);

comes across as expedient (though noisy) and perhaps receiving less thought than it deserves.

Jon Silver • Jun 20 '21

There's an npm library that does exactly this. (Full disclosure: I wrote it and have been using it for a couple of years)
npmjs.com/package/@jfdi/attempt

peerreynders • Jun 22 '21

All approaches have their trade-offs.

The Zen of Go:

Plan for failure, not success

Go programmers believe that robust programs are composed from pieces that handle the failure cases before they handle the happy path.

Go's errors are values philosophy is a recognized pain point.

Handling errors where they occur - midstream - obscures, in use case terminology, the happy path/basic flow/main flow/main success scenario. That doesn't mean that other flows/scenarios aren't important - on the contrary. That's why there are extensions/alternate flows/recovery flows/exception flows/option flows.

Clearly identifying the main flow in code is valuable.

Whether or not an IDE can collapse all the conditional error handling is beside the point - especially given that traditionally Java has been chastised for needing an IDE to compensate for all its warts.

to implement functional try/catch

Granted Go doesn't use a containing tuple like [error, result] but destructuring still directly exposes null or undefined values which is rather "un-functional" - typically the container (the tuple) is left as an opaque type while helper functions are used to work with the contained type indirectly (e.g. Rust's Result).

Now your criticism regarding try … catch is fair …

a variable ripe for mutation

… but JavaScript isn't a functional language (which typically is immutable by default and supports the persistent data structures to make that sustainable). However it is possible to take inspiration from Rust:

If a variable has unique access to a value, then it is safe to mutate it.

Rust: A unique perspective

e.g. for local variables with exclusive/unique access (i.e. aren't somehow shared via a closure) mutation can be acceptable.

So maintaining a context object to "namespace" all the values that need to stretch across the various try … catch scopes isn't too unreasonable:

const hasValue = (result) => result.hasOwnProperty('value');

class Result {
  static ok(value) {
    return new Result(value);
  }

  static err(error) {
    return new Result(undefined, error);
  }

  constructor(value, error) {
    if (typeof value !== 'undefined') this.value = value;
    else this.error = error;
  }

  get isOk() {
    return hasValue(this);
  }

  get isErr() {
    return !hasValue(this);
  }

  map(fn) {
    return hasValue(this) ? Result.ok(fn(this.value)) : Result.err(this.error);
  }

  mapOr(defaultValue, mapOk) {
    return hasValue(this) ? mapOk(this.value) : defaultValue;
  }

  mapOrElse(mapErr, mapOk) {
    return hasValue(this) ? mapOk(this.value) : mapErr(this.error);
  }

  andThen(fn) {
    return hasValue(this) ? fn(this.value) : Result.err(this.error);
  }

  // etc
}

const RESULT_ERROR_UNINIT = Result.err(new Error('Uninitialized Result'));

// To get around statement oriented
// nature of try … catch
// wrap it in a function
//
function doSomething(fail) {
  // While not strictly necessary
  // use `context` to "namespace"
  // all cross scope references
  // and initialize them to
  // sensible defaults.
  //
  const context = {
    success: false,
    message: '',
    result: RESULT_ERROR_UNINIT,
  };

  try {
    if (fail) throw new Error('Boom');
    context.success = true;
    context.result = Result.ok(context.success);
  } catch (err) {
    context.success = false;
    context.message = err.message;
    context.result = Result.err(err);
  } finally {
    console.log(context.success ? 'Yay!' : `Error: '${context.message}'`);
  }
  return context.result;
}

const isErrBoom = (error) => error instanceof Error && error.message === 'Boom';
const isErrNotTrue = (error) =>
  error instanceof Error && error.message === "Not 'true'";
const returnFalse = (_param) => false;
const isTrue = (value) => typeof value === 'boolean' && value;
const isFalse = (value) => typeof value === 'boolean' && !value;
const negate = (value) => !value;
const negateOnlyTrue = (value) =>
  isTrue(value) ? Result.ok(false) : Result.err(new Error("Not 'true'"));

// hide try … catch inside `doSomething()` to produce a `Result`
const result1 = doSomething(false); // 'Yay'
console.assert(result1.isOk, 'Should have been OK');
console.assert(result1.mapOr(false, isTrue), "Ok value isn't 'true'");
console.assert(
  result1.map(negate).mapOr(false, isFalse),
  "'map(negate)' didn't produce 'Ok(false)'"
);
console.assert(
  result1.andThen(negateOnlyTrue).mapOr(false, isFalse),
  "'andThen(negateOnlyTrue)' didn't produce 'Ok(false)'"
);
console.assert(
  result1
    .map(negate)
    .andThen(negateOnlyTrue)
    .mapOrElse(isErrNotTrue, returnFalse),
  "'andThen(negateOnlyTrue)' didn't produce 'Error(\"Not 'true'\")"
);

const result2 = doSomething(true); // "Error: 'Boom'"
console.assert(result2.isErr, 'Should have been Error');
console.assert(
  result2.mapOrElse(isErrBoom, returnFalse),
  "Message isn't 'Boom'"
);
console.assert(
  result2.map(negate).mapOrElse(isErrBoom, returnFalse),
  "'map(negate)' didn't preserve Error"
);
console.assert(
  result2.andThen(negateOnlyTrue).mapOrElse(isErrBoom, returnFalse),
  "'andThen(negateOnlyTrue)' didn't preserve Error"
);

Muhammad Ovi • Jun 20 '21

Thank you for sharing <3

Muhammad Ovi • Jun 19 '21

But what if we have all the promise dependend on promise above them, and we want to handle error for each of them?

Khorne07 • Jun 18 '21

Simple and powerful solution 👌

Acid Coder • Feb 4 '22

the "standardized error handling function" may seem nice, but it forces you to handle each error individually, you need to check the error for every statement with if else, resulting if else tower of terror and we are back to square one

meanwhile promise.all did a better job in handling all error with one catch

Basharath • Jun 22 '21

const promise = new Promise((res, rej) => {});

// promise is a promise.

Basharath • Jun 21 '21

Yes, but they are promises not functions returning promises.

Basharath • Jun 21 '21

You just need to pass the function(Promise) references in Promise.all