Errors Are Not Exceptions

source: devto devToUrl: "https://dev.to/swyx/errors-are-not-exceptional-1g0b" devToReactions: 97 devToReadingTime: 5 devToPublishedAt: "2021-01-29T15:18:16.000Z" devToViewsCount: 2502 title: Errors Are Not Exceptions published: true description: Many language ecosystems use try/catch paradigms to represent both errors and exceptions. This is wrong. tags: languages, golang, javascript slug: errors-not-exceptions canonical_url: https://www.swyx.io/errors-not-exceptions

listen to me explain this in a podcast

TL;DR

Errors are unrecoverable, Exceptions are routine.
Most languages (Java, PHP) build the distinction into the language. Yet others (Go) name them the other way round. Some languages (JavaScript, Python) treat them as synonyms.
No matter what way you name things, you should handle Errors and Exceptions separately in your code or bad things happen.

Because I started out in JS/Python and then went to Go, without touching Java, getting this distinction right took me a few hours of thinking and research. It's not self-evident!

Context

If you've ever thrown an error in a function expecting its invoker to catch it, you're doing it wrong.

Ok, I'll admit I'm just hamming up a mere opinion for a more eye-catching opening. But I do feel strongly about this so...

I was recently reminded of this while going through the Go FAQ and being reminded that Go does not have exceptions.

What? If you've always coded in a language that has exceptions, this ought to jump out at you.

Go does not have try or catch. Despite those language constructs existing for decades, Go chose to have Defer, Panic, and Recover instead. By convention and design, Go encodes an extremely strong opinion that errors should be returned, not thrown.

But Why

Relying on exception handling to handle errors either leads to convoluted code or unhandled errors.

This kind of code is common in JavaScript:

function trySomethingRisky(str) {
        if (!isValid(str)) throw new Error('invalid string!')
        return "success!"
}

function main() {
    try {
        return trySomethingRisky(prompt('enter valid name'))
    } catch (err) {
        if (err instanceof Error) {
            // handle exceptions
        } else {
            // handle errors
        }
    }
}

If you're thinking that you don't write this sort of code very often, you're probably not thinking through your failure modes enough.

JavaScript doesn't have a native way to indicate whether a function can throw, if you invoke it. So you cannot lint against it — you must either pay this cost earlier in manual code review or later in bug reports.
An innocent fs.readFileSync call can bring down a whole server (or memory-leak descriptors) given the wrong string.
Promise calls without a catch in the browser will simply log silent errors (a terrible user experience).

The more function and module boundaries you cross, the more you need to think about defensively adding try/ catch and handling the gamut of errors that can happen, and the harder it is to trace where errors begin and where they are handled.

Aside - some authors like this Redditor and Matt Warren make a performance driven argument for encouraging developers to not overuse exceptions. Exceptions involve a memory and compute intensive stack search. This matters at scale, but most of us will never run into this so I choose not to make a big deal out of it.

Errors vs Exceptions

Let's attempt a definition:

Exceptions are expected failures, which we should recover from.
Errors are unexpected failures. By definition, we cannot recover elegantly from unexpected failures.

You might notice the ironic inversion - it is errors that are "exceptional", while exceptions are routine. This was very confusing to your humble author.

This is no doubt due to the fact that JavaScript, Python, and other languages treat errors and exceptions as synonyms. So we throw Errors when we really mean to throw exceptions.

PHP and Java seem to have this difference baked into the language.

To make things extra confusing, Go uses error where other languages would call exceptions, and relies on panic to "throw" what other languages would call errors.

Notes: Chris Krycho observes that you can use Rust, F#, and Elm's Result in a similar way, and Haskell's Either.

Exception Handling vs Error Checking

The realization that we need different paradigms for handling errors and exceptions is of course not new. Wikipedia's entry on Exception Handling quotes Tony Hoare (creator of QuickSort, CSP and the null reference) saying that exception handling is "dangerous. Do not allow this language in its present state to be used in applications where reliability is critical."

That was said in 1980, yet here we are 40 years later.

The alternative to exception handling is error checking.

Error Checking in Go

Note: Go seems to have a strong opinion that "Errors" are routine and Exceptions (not formally named, but used in panic) are Exceptional - in direct opposition to other languages. I have opted to use Go-native terminology - minimizing confusion locally at the cost of increasing global confusion.

Errors are values in Go — made to be passed, not thrown. Go's FAQ is worth quoting here:

We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

When something goes wrong, your default choice should be using multi-value returns to report errors:

i, err := strconv.Atoi("42")
if err != nil {
    fmt.Printf("couldn't convert number: %v\n", err)
    return
}
fmt.Println("Converted integer:", i)

This pattern would be subject to the same weaknesses I outlined above, except for the fact that Go will refuse to compile if you 1) don't assign all returned values at the callsite or 2) don't use values that you assign. These two rules combined guide you to handle all errors explicitly near their origin.

Exceptions still have a place — but the language reminds you how rarely you should use it, by calling it panic(). You can still recover() and treat it like a backdoor try/ catch in Go, but you will get judgy looks from all Gophers.

Error Checking in Node

JavaScript lacks the 2 features I mention above to force you to handle errors.

To work around this and gently nudge you, Node uses error-first callbacks:

const fs = require('fs');

function errorFirstCallback(err, data) {
  if (err) {
    console.error('There was an error', err);
    return;
  }
  console.log(data);
}

fs.readFile('/some/file/that/does-not-exist', errorFirstCallback);
fs.readFile('/some/file/that/does-exist', errorFirstCallback);

This pattern is idiomatic in most Node libraries, but the further we get away from Node, the more we tend to forget that there is an alternative to throwing errors, when writing libraries and app code.

Lastly, it is tempting to promisify those callbacks:

const util = require('util');
const fs = require('fs');

const stat = util.promisify(fs.stat); // i am using fs.stat here, but could be any error-first-callback userland function

// assuming top-level await
try {
    const stats = await stat('.')
    // do something with stats
} catch (err) {
    // handle errors
}

And we are right back where we started - being able to fling errors and exceptions arbitrarily high up and having to handle both in the same place.

swyxio / swyxdotio