The Utter Failure of the JS Error (and why you should still use JS)

Michael Interlandi — Mon, 27 Apr 2026 16:20:46 +0000

The Sin of Simplicity

3.4 million years ago, apes began to demonstrate the ability to use tools.
Impressively, by 1995, those same apes could write dynamic web pages. Back
then, the majority of those apes were writing linear scripts with very few potential failure modes. They had yet to encounter the dense forest of AJAX, or the swamplands of the permissions API and its apex predator, getUserMedia. No, at this point in history, they were still enchanted by the dry savanna of client-side form validation.

Back then, the amount of ways a JavaScript application could fail was relatively small, and in the majority of failure cases, it didn't really matter how you responded (if at all).

Take the following, for example.

function validateForm() {
    // 1. Check if the name field is empty
    if (document.myForm.userName.value == "") {
        alert("Please enter your name.");
        document.myForm.userName.focus();
        return false;
    }

    // 2. Check if the age is a number
    var ageValue = document.myForm.userAge.value;
    if (isNaN(parseInt(ageValue))) {
        alert("Please enter a numeric age.");
        document.myForm.userAge.select();
        return false;
    }

    // If all checks pass
    alert("Form is valid! Submitting...");
    return true;
}

This was just about the most complex JS code anyone had written at the time. In this function, the closest thing to failure is the violation of the form invariants.

Now, let's consider something you might write today.

async function getUserData() {
    const response = await fetch('/api/user/1'); 
    const data = await response.json(); 
    console.log(data);
}

How many places can this fail? I'll save you the suspense. It's at least this many:

async function getUserData() {
    // failure modes: 400/500 errors; literally any network-related error
    const response = await fetch('/api/user/1'); 

    // failure mode: .json() throws if response is empty or invalid JSON
    const data = await response.json(); 
    console.log(data);
}

So, how do you handle this? Maybe …

async function getUserData() {
    try {
        const response = await fetch('/api/user/1'); 
        const data = await response.json(); 
        console.log(data);
    } catch (error) {
        console.error('Error: ', error);
    }
}

The problem? When something does go wrong, we have absolutely no idea what actually failed.

There's more than one way to handle this, but I'll pick this one for the sake of argument.

async function getUserData() {
    try {
        const response = await fetch('/api/user/1'); 
    } catch (error) {
        console.error('Fetch failed:', error);
        return
    }

    try {
        const data = await response.json(); 
    } catch (error) {
        console.error('Failed to parse response as JSON:', error);
        return
    }

    console.log(data);
}

Now, look me in the eyes and tell me you'd actually write the last one at 4:55 PM on a Friday.

Therein lies the problem. You have to explicitly declare "I would like my consumer to function properly" at every potential failure point. When every single line of code is a potential failure point, try/catch, is just the wrong abstraction. That's opt-in predictability, where predictability can be defined as, at best, the absence of negligence.

That design philosophy made sense when the happy path was the only path you realistically needed to worry about. Now, though, we write actual libraries and applications with JavaScript.

As the language grew, its error handling didn't, and now exists purely as a vestige of humble beginnings.

Simplicity Built on Complexity Is Just Hidden Complexity

Imagine the flow of data through your (JS) program's call stack looks like this.

Straightforward, right? No.

The above topology is incomplete. Here's what it actually looks like.

Now, please reread the section title.

Simplicity Built on Complexity Is Just Hidden Complexity

I'll connect the dots for you in a second, but I'd assume many of you already know where I'm going with this.

The "hidden complexity" here is the fact that your program can actually fail. I don't know about the rest of the "ape with keyboard" population, but personally, I feel that Brendan Eich may not have had the utmost confidence in our collective intelligence when he made the decision to hide this from us.

As someone who writes a lot of library-level code, I'm the kind of person this burden ultimately falls on. That said, if you have ever written JavaScript/TypeScript that gets called by anything ever, then you are also that kind of person.

If you dare to call functions, then you are also affected. Often, you have no way of knowing whether the thing you are using is going to throw unless you read the source. If it's invisible to the type system, it's invisible to the consumer. I need not explain further why this is bad.

None of this is meant to surprise you or present itself as a novel idea. In fact, if I've done my job right, you've been thinking "yeah, I know" this whole time.

So, what now?

How to Fail Correctly

Rust is not perfect by any means, but I enjoy writing it far more than I enjoy writing TypeScript. A surprising amount of that fact can be attributed to its philosophy around what "errors as values" actually means.

Since you're already familiar with this form of diagram, here's the Rust version:

The keen-eyed among you will have noticed something shocking: the two columns have merged! Instead of insultingly obfuscating your program's error economy from you, Rust forces you to think about it.

If your eyes were made for the beautiful : of TypeScript, and not the -> of Rust, you have permission to close them, but be warned, this code will still be there when you open them.

fn get_user_data() -> Result<User, UserDataError> {
    let response = get("/api/user/1")?;
    let data = response.json()?;
    Ok(data)
}

If you're unfamiliar with the pattern, a Result<T, E> is just a monoid in the category of endofunctors. You can think of it as a discriminated union that wraps some "good" value T in the event of a successful call, or some error E in the event of an error.

The ? operator is syntactic sugar that propagates errors up the call stack. If get() fails, the function returns early with the error. If response.json() fails, the function returns early with that error. The caller now has complete visibility into what failed without any try/catch boilerplate.

How do you consume this function? Rust has a number of idioms for dealing with this, some markedly more attractive than others. To showcase one that I'm particularly fond of that isn't the ? operator, I'll show you the following.

fn print_user_data() {
    let data = get_user_data()
        .unwrap_or_else(|| get_cached_user_data());

    println!("{:?}", data);
}

unwrap_or_else is very powerful as used above. It allows the expression get_cached_user_data() to be lazily evaluated, meaning the cache is only invoked when it has to be.

This is to illustrate that Rust, in being very explicit in its error handling philosophy, allows you to easily define exactly how much you care about if, how, or in what context something fails, and how you'd like to deal with that failure.

For example, you have to explicitly tell the compiler that failure is not an issue:

// (Usually) won't compile.
fs::remove_file("/tmp/temp_cache");

// Failing to remove a temp file is probably fine,
// and this is how we tell the compiler (actually, the linter in this case).
let _ = fs::remove_file("/tmp/temp_cache");

// Note: Any binding called _ is not a binding at all, rather,
// a placeholder that tells Clippy, Rust's canonical linter, to ignore a value 
// (as is emulated in most of your ESLint configs, I'm sure).

Whereas, in TypeScript you have to explicitly state that failure IS an issue.

That's a strange thing to have to say about failure.

`neverthrow` and the `thiserror`-shaped Hole

If you're really deep in the TypeScript rabbit hole, you know exactly what this section is about. The gorgeous, unapologetically Rust-like time sink that is neverthrow.

If you're unfamiliar, here's everything I knew when I wrote my first line of neverthrow-flavored TypeScript:

async function getUserData() {
    const response = await fetchFromAParallelUniverse('/api/user/1'); // returns a neverthrow Result<UserData, SomeErrorType>
    if (response.isErr()) { // This method is on all neverthrow Results
        console.error('Fetch failed:', response.error); // We can extract the inner error using the `error` member.
        return
    }

    // We can extract the inner value by using the `value` member.
    const data = await response.value.json(); 
    if (data.isErr()) {
        console.error('Failed to parse response as JSON:', error);
        return
    }

    // TypeScript knows that value is defined, but error is not at compile time.
    console.log(data.value);
    tryToConsume(data.error);
    //                 ^? undefined
}

To be clear, neverthrow isn't the only solution to this problem, but I'd recommend it over something like Effect to most people grasping the pattern for the first time, since it doesn't require you to port your prefrontal cortex to Haskell.

The important thing to note here is that you don't get to use the inner value until you've acknowledged the failure case. This necessarily inverts the usual TypeScript paradigm:

… in TypeScript you have to explicitly state that failure IS an issue.

However, a question is yet unanswered here, and it actually exists in the Rust examples as well:

What type are the errors?

The usual TypeScript answer to this question is "I dunno, Error?", and this is actually the case more often than not even with neverthrow.

Within the Rust ecosystem, there are a few good answers. The application developer-sanctioned choice, is anyhow. It's effectively a set of tools for working with a single anyhow::Error type that can consume any error you can think of with minimal keystrokes.

If you ask a library developer, they'd tell you about thiserror, whose claim to fame is its ability to allow you to easily define custom error types, again, with minimal keystrokes.

In TypeScript, however, this is impossible, because thiserror's primary ergonomic benefit is driven entirely by Rust's powerful metaprogramming functionality.

This is the hole. You can get really close, but inverting paradigms is as hard as inverting (I really tried to find a good way to finish this sentence, so use your imagination). Metaprogramming simply does not exist in TypeScript, so if you want to use neverthrow as divinely ordained, you're gonna be writing some boilerplate.

And yet …

You Should Still Use JS

The point of this article is not to pit JS against Rust. That's a silly comparison. They solve fundamentally different problems for different people with different constraints.

Rather, my intention was to explore my personal biggest problem with JS, and be specific about what a good solution to that problem actually looks like.

Do I think we will ever see Rust-like error handling as a first-class citizen? For a multitude of reasons, almost certainly not (as much as I would like to be proven wrong).

JS is a microcosm of its own flaw. It's not conceptually attractive, nor philosophically correct, but it ships software.

Why?

Because the entire planet already depends on this nuclear pile of [object Object].

If you have a problem in TypeScript, there's a good solution written in TypeScript. If you have a problem in Rust, there's a solution written in Rust with zero documentation, and a solution written in C with Rust bindings with zero documentation.

The corpus of public TypeScript code is an order of magnitude larger than that of Rust. This poses more potential benefits than just the above, such as the fact that LLM inference over TypeScript code is categorically better than that over Rust code.

Hence, if you want to go home at 5:00 o'clock, and don't have a compelling reason to use something else, you should be writing JS/TS.

Yes, it has absolutely no business being as relied upon as it is.

Yes, its answer to error handling becomes a burden as soon as you try to step outside the boundaries of what it was originally designed for.

Yes, it (insert any of the million things wrong with JS).

Use it anyway.

The language doesn't deserve you, but here we are.

DEV Community: Michael Interlandi

The Utter Failure of the JS Error (and why you should still use JS)

The Sin of Simplicity

Simplicity Built on Complexity Is Just Hidden Complexity

How to Fail Correctly

neverthrow and the thiserror-shaped Hole

You Should Still Use JS

`neverthrow` and the `thiserror`-shaped Hole