All languages have, so far, reached a certain point in their development: error handling. JavaScript, like most languages, chose try-catch statements. This way of error handling, however, is often worse than it is good, despite doing some things right.

What do they do right?

Back when programs were simple and linear, Exceptions were a great way of error handling: they force the programmer to handle any possible errors, or else the program crashes.

So, all developers had to either handle possible errors or risk their program crashing out of nowhere. This was by purpose — it was a simple yet efficient way to get developers to handle issues.

What do they do wrong?

While try-catch used to be a great way of handling errors, the more branching and complexity you add, the more annoying it is to use it.

Let’s take this scenario:

async function doSomething(key) {
    const resource = await fetch("/v2/data");  // Can fail on network error
    const data = await resource.json();  // Can fail if JSON is invalid
    const value = data[key];
    return value;
}

This small example can throw two different errors. Let’s see how you would normally handle them:

async function doSomething(key) {
    let resource;
    try {
        resource = await fetch("/v2/data");
    } catch {
        console.error("Failed to get resource.");
        return undefined;
    }
    let data;
    try {
         data = await resource.json();
    } catch {
        console.error("Failed to parse response JSON.");
        return undefined;
    }

    const value = data[key];
    return value;
}

So, just to fetch some data and retrieve a value, we need two try-catch statements.

Let's rewrite that with a single try-catch statement:

async function doSomething(key) {
    try {
        const resource = await fetch("/v2/data");
        const data = await resource.json();

        const value = data[key];
        return value;
    } catch {
        console.error("An error occured.");
        return undefined;
    }
}

While this works, the error handling here is far too broad for modern codebases.

The solution

So, exceptions are messy. The solution? — Errors As Values (yes i typed that em-dash by hand).

Let's see what that exact same code would look like if fetch(), .json(), and key indexing all used Errors As Values instead of throwing an Error.

async function doSomething(key): [unknown, Error | null] {
    const resource = await fetch("/v2/data");
    if (!resource)
        return [undefined, new Error("Failed to fetch resource")];

    const data = await resource.json();
    if (data === undefined)
        return [undefined, new Error("Failed to parse response JSON")];

    const value = data[key];
    return [value, null];
}

const data = await doSomething("myKey");

if (data[0])
    console.log(data[0]);
else
    console.error(`New Error: ${data[1]}`);

Notice how much shorter it is, while still allowing the developer to handle errors?

A good example of Errors-As-Values is Effect, which, despite its steep learning curve, provides a great implementation of Errors-As-Values.

Not everyone is willing to learn an entirely new framework, though (especially not one that involves whatever yield* myFunc() is). Good news is: you don't need to; you can very easily implement your own basic version of this. Here is an example:

type ExpectedType<T, E> = {success: true, data: T} |
        {success: false, data: E};

const ok = (v) => ({success: true, data: v});
const fail = (e) => ({success: false, data: e});

async function doSomething(key): ExpectedType<unknown, Error> {
    const resource = await fetch("/v2/data");
    if (!resource[0])
        return fail(resource[1]);

    const data = await resource.json();
    if (!data[0])
        return fail(data[1]);

    const value = data[key];
    return ok(value);
}

const data = await doSomething("myKey");

if (data.success)
    console.log(data[0]);
else
    console.error(`New Error: ${data[1]}`);

(ShowDev) Writing a makeshift solution

Just so I could have a simple solution to this problem, I wrote ErrorsAsValuesTS — a library designed specifically for Errors-As-Values error handling.

Here's an example of the above code with this library:

import { Expected } from "errorsasvaluests";

async function doSomething(key): unknown {
    const resource = await fetch("/v2/data");

    const data = await resource.json();

    const value = data[key];
    return value;
}

const value = await Expected<unknown, Error>.run(doSomething, ["myKey"]).onError(
    e => { console.error(`New Error: ${e}`); }

if (value !== undefined)
    console.log(value);
);

This code snippet runs doSomething("myKey"). If any error is thrown, value becomes undefined and that arrow function is called. If no error is thrown, value becomes the returned data. Simple enough, yet robust. No more reading source code to see what errors can be thrown (they are now typed), no more forgetting to handle errors.

So why doesn't JavaScript throw away Exceptions?

Simple answer — it can't.

Long answer — all existing infrastructure running on JavaScript/TypeScript already assumes, and relies on, Exception-based error handling. All of the existing Node programs, all of the existing websites, they all assume Exception-based error handling. If JavaScript suddenly moved away from Exceptions, years of backwards compatibility would be lost, and the costs of switching to a new method of handling errors would be massive.

Conclusion

Exceptions work for simple, linear programs, but they are severely limited in real-world applications. They are still useful, however, for backwards-compatibility purposes.

I am not saying JavaScript is bad for having used Exceptions, nor am I implying anything bad about JavaScript itself. Instead, exceptions shouldn't generally be used by libraries, modules or normal codebases unless there is a really good reason for it, and you should instead prefer using simple Errors-As-Values implementations or just going for Effect (or an errno()-like implementation, if you wish). How you implement Errors-As-Values doesn't matter; if done properly, it will make your codebase easier to work with.

Additionally, Exceptions remain a good idea for actually exceptional issues that shouldn't normally appear, but are arguably worse for structured control flow or expected errors.