Elegant Error Handling with the JavaScript “Either” Monad (jrsinclair.com)

It reminds me of what svg text rendering looked like in 2001 using IE and the svg plugin from adobe.

The whole site is incredibly hipster

The code samples look okay for me (did the author tweak the stylesheets?), but the text uses an 'engraved' look using CSS's text-shadow (like iOS Notes but a bit worse because of the serifs) which makes it a bit hard to read.

This is where browsers' reader modes really help. Is Chrome the only one now that doesn't natively support reader mode? Reader mode in Firefox made this much easier to read.

>font that looks like it's been printed on paper with poor ink

Actually, I think it is intended to look like mechanical typewriter output.

Agreed. I never understood the love for Either-based error handling in Haskell and other languages. It's such a bare bones system. If you add all the features that people want from an error handling system, like stack traces; and remove the misfeatures that nobody wants, like Either<IOError,Either<MathError,Result>> being a pointlessly different type from Either<MathError,Either<IOError,Result>>; you end up with (surprise!) try-catch.

> stop trying to be so clever - focus on writing clean, readable, simple code.

That's exactly what using either instead of try/catch does! try/catch are magic language keywords that create invisible, surprising control flow. Either is plain old code written in the normal language, with functions that follow the normal rules.

Maybe in plain JS, but with Typescript this Either pattern will force you to handle errors unlike untyped try, catch.

I don't use this pattern to deal with the problems in my day to day JavaScript code in case other people confuse. I just think it's unfair to simply believe this is complex. It's simpler on mental. I'm not encouraging people to use this style, it's just some random defense.

This pattern is not more complex than try/catch. It's just JavaScript lack constructs to make the writing much less verbose. (we could abuse async/await but it's tricky).

Try/catch is an extra language construct which is confusing - it has dynamic semantics just like JavaScript's weird 'this' behavior. And it's leaky just like null - when you forgot to handle something, the whole thread explodes. Besides, it's not an expression, which means it's harder to refactor or return with function, passing as an argument, etc. On the contrary, Either would be just fine everywhere, just typical functions and values.

Another use case is when you want to collect the errors along the road, instead of failing fast behavior, in this case, Either would be easier than try/catch.

Saying something is superficial and too clever is not a counter argument, but rather a reaction, I think, to it being radically different from what you're used to. I'm not saying it's necessarily better, but maybe approach things with an open mind.

Readable functional programming imo really hinges on some essential basic language primitives. Those are sum types, pattern matching, and restricting mutability.

Forcing sum types onto a language that does not support them is bound to end in awkwardness and reduced readability without providing the real benefits of increased correctness.

This is a great example. std::option from C++ is another one.

Fully agree. I'm not a JS expert by any means, but I dabble here and there, mainly for work.

If someone did this at work, I'd wonder why they are trying to add so much complexity to something that is rather simple and already well understood by most.

It would be hard to convince me to sign off on a code review where this was added tbh. I'd love to hear how/why I'm wrong here though.

Maybe there are better use cases for it? But in my case, the major thing I care about is that code is simple and readable.

Absolutely agree. This is very clever and it makes the "puzzle" part of my brain happy in the same way writing a program in "OOK!" does.

That said, I work with quite a few juniors. You should absolutely not use this in production.

Samesies. Worked with a bunch of folks who liked bringing functional patterns into JS when that started to get trendy, and I got it, but I never got it. Like, why. Never felt like it was making my life easier.

When I've felt the best writing JS was back when it was a much worse language (which is saying something) and I wrote it about as close to C as I could manage. But then I've always thought the prototypal object model is a giant footgun with little legitimate purpose and any "clever" use of it's simply a bad idea, so maybe I'm just inflexible. I also think modern classes are entirely fine, even good, for Reactjs, and adding more patterns just to be more "functional" (but not really—look under the hood) is a very bad idea, but I seem to be nearly alone in that.

[EDIT] never got why in JS specifically. I get how in a language with proper support for it functional style can be nice. And it's fine in certain narrow cases of course—a little recursive function or simple list processing code, for instance, just not as a broad, principled pattern to apply to as much of a JS codebase as you can manage.

JavaScript does not make it easy. I'm having the same issue as I move towards more functional code in a large React codebase. I'm wanting to adopt more of these patterns but the JS language makes it difficult.

Specifically, JavaScript's lack of infix operators, pattern matching, type classes, and `do` notation make the code harder to read.

I've had good success using the Ramda library. It provides a lot of functional style programming helper functions but still feels good in native JS.

I have to admit, if I ran into this style in a real Javascript codebase, I'd run screaming into the woods.

It could possibly make sense in Typescript, depending on how good generics are.

But, generally, functional programming really shines when you have build-time type enforcement so you're not guessing as to whether things will work together.

In dynamically typed languages, all you know about a function is that its arguments have names and it returns a value. You can have some wonderful free-monads, but you're left to run the code, see it crash, and ponder stack traces or reason through why it failed. (Assuming it's nice enough to fail obviously.)

So you get lured in by how cool it is, but then the moment you use functional techniques beyond what you can fit in your head, you find your tooling gives you no support whatsoever.

You should never have unexpected exceptions if you embrace static typing and one of the many libraries that take this idea and do it better, for example `purify-ts`. It also comes with methods included for statements that might throw such as `JSON.parse`.

> The 'Either' monad looks like a JS Promise without the asynchronicity.

Congratulations, you're discovering the general concept of monads :). By formalising that "looks like" you can write functions that operate generically on both, and even on other constructs that conform to the same interface.

> I understand that using Promises for error handling has some advantages in very unusual situations. But for the most part, I am happy about the greater readability and lower complexity that async/await offer.

It's always the edge cases that get you. Naively-implemented async/await do the right thing most of the time - and then they break down in exactly the most complicated cases where you really can't spare the mental capacity to deal with them doing something surprising.

If you implement async/await as lightweight syntax sugar over promises, then you get the best of both worlds: you have lightweight syntax for the simple cases, but can always fall back to the more explicit approach for the confusing cases. Similarly, if you implement throws/try/catch as lightweight syntax sugar over either, you can have the best of both worlds. Better still, you can implement a generic lightweight syntax sugar that's usable for any of these kinds of constructions: "do notation" in Haskell, or "for/yield" in Scala.

Yes, Promises are similar to monads but they don't obey all the monadic laws; as a result they don't compose as well.

This means that you're always "stuck in the weeds" of promises and can't write code that abstracts it away. Or that treats promises, observables, arrays, etc, exactly the same since they all have different "interfaces".

In that sense JS is more complicated because other languages don't make you learn different syntax and APIs for each one.

Indeed. For a while we focused on the happy path/MVP, and I was amazed how quickly edge-cases start piling up and sinking the ship with endless fixing/debugging/rework tasks. Now, we start with failure-cases first, engineer for resilience, and only then think about features. In consumer tech, failure rates of 2-5% often will not even trigger PagerDuty, but in enterprise that gets you fired real quick.

I wanted to coin a term for this. Failure oriented programming. State what it MUST NOT be, then the happy path will emerge.

I would say this is why monads such as Either, and Optional, are so important. They require the programmer to deal with the dark path or at least make it explicit when there is a dark path. I first encountered these monads writing Scala years ago, and although it takes some getting used to, I always use them now in my Java day job to communicate the dark path.

Requiring functions to be "total" functions is another way to look at it. I like languages with pattern matching that will generate a compiler error if you don't handle all possible paths.

I think you may like Monads for exactly the reasons you described though, I wouldn't focus too much on this particular sentence.

Monads for error handling are very similar to exceptions - they let you write your code in terms of only the happy path, but letting each step fail the entire computation if something unintended happens (with a relevant error). They also have some advantages if you like to be explicit about the "dark path".

1) In traditional imperative programming you have to make a choice between errors as exceptions (implicit) and errors as return values (explicit) - monads let you do both at the same time in a sense --- whether you get implicit or explicit behaviour depends on how you "glue" computations together.

2) Monads are more explicit about when a dark path exists in the sense that they will have a different type signature and often different syntax (at least in haskell/c#/scala and other languages that support explicit monad-based notation)

I'm not a huge fan of Monads for error handling in languages like Javascript without explicit support for them though, mostly as they just don't read very well.

It probably depends on the kind of software more than the industry, but in my experience, the unhappy path is usually 'bubble up until you get to some user input', with some careful use of destructors/dispose to undo some complex operations.

Exceptions cover this in the best way, since, unlike monads, they actually give you a pretty accurate idea of where the code was when the error happened,whule still playing very nicely with pure functions in the callstack ( which don't have to start adding error handling/logging logic simply because callbacks they use may fail).

With static typing: https://www.npmjs.com/package/minimal-result

And if you don't, you can just take your throwing function, wrap it in a try-catch, and return errors. Voila, callers will have no idea it's really using exceptions inside.

What is foolish about the naming? It's a Bifunctor and while often used for error handling in programs it actually has nothing to do with error handling.

The naming, afaik, comes from the correspondence to the logical disjunction operator and so the constructors name the Left side of the disjunction and the Right side of the disjunction. Seems rather sensible to me.

Haskell's Either isn't intended to be used solely as Left = Err and Right = Ok. It's supposed to work as an abstract concept of "one thing or another", and the language designers have avoided choices that would canonicalize it that way, such as introducing a MonadFail (Either String) instance.

One example of why you would buck the trend would be to use of Left = Ok and Right = Err for a series of "retry" computations. Say you have a few functions of type Either a String, which all get progressively slower, but which work on progressively more advanced input. An example might be a series of regex engines, each of which run slower but handle more and more advanced lookahead syntax. You can then write something like:

    makeRegex :: String -> Either Regex ParseError
    makeRegex regexExpression = makeBasicRegex regexExpression >> makeLookaheadRegex regexExpression

This will return a Regex using a simple parser if it can, and if that function fails (by returning a Right value!) it will go onto the next function and try that.

    List<LocalDate> dobs = users.stream()
        .map(person -> Either.either(person::getDeprecatedDob, person::getDobLocalDate))
        .map(oldOrNewFormat -> oldOrNewFormat.fold(
            (Date oldFormat) -> convertOldFormatToNew(oldFormat),
            (LocalDate newFormat) -> newFormat,
         ))
        .collect(Collectors.toList());

That works well for simple programs, but if you write at scale, that style of programming is very error prone and tedious.

It introduces a lot of noise into the program and makes it harder to follow the logic.

If you don't lift yourself into higher levels of abstraction, it's much harder to focus on more difficult problems. For example, long division with Roman Numerals is more difficult than Arabic because there are simply more low level details to worry about.

I pretty much agree with you.

I hate error handling in JS. It's messy, it's really REALLY hard to get right, every single project has to layer on their own ways of handling it since the only thing the language gives us is the ability to `throw` and `catch` (even the "standard error" object doesn't have anything other than a place to put a string).

It's a giant mess, and I'd love to find a way out, but I think it has to come from the language itself. Trying to shoehorn JS into a fully functional language leads to a lot of scaffolding and "custom" piping to get it to work, and in 100% of the situations I've seen it done it's been harder to maintain the scaffolding (and wrap 3rd party code to work in the way you need it to) than it ever would be to manage exceptions.

I'll admit to be fairly ignorant of the different ways of handling exceptions in other languages. For the most part I've really only experienced try/catch, multiple-returns (golang style), and whatever bastardization JS is at now (try/catch + .then/.catch + custom error objects) in production codebases. But that solution needs to be part of the language not bolted on in userland. Mainly so that you don't need to write all this piping to get the rest of the ecosystem to behave in the way you want/need.

FWIW Rust's Result type is beautiful and seems to solve a lot of issues (from the very small amount of experience I have with it), but trying to use that in JS is only going to lead to trouble without some help from the language itself.

> 1. You aren't forced to write it. It's simply possible to forget that a function might fail (e.g. when that failure is defined as a side-effect).

When the compiler does require you to explicitly acknowledge exceptions (Java), people hate it.

"That's silly because the benefits of this type of programming can't be grokked until you use it on real projects.. it's honest-to-goodness not enough to look at small examples and judge whether it's worthwhile or not."

But you can look at small examples and decide that the syntax noise isn't worth it.

It's almost always a good idea to write "$LANGUAGE in $LANGUAGE" and not write "Fortran in $LANGUAGE" or "Haskell in $LANGUAGE". Importing these idioms into JS is pretty much the latter. You pay costs you don't pay in Haskell, and you don't get advantages that you can get in Haskell. It shouldn't be a surprise that the cost/benefit analysis for the constructs in JS can result in a very different one than the one for Haskell. You can't just substitute the analysis for Haskell and assume that it's all the same everywhere else.

It's not "elegant". It's importing what is an elegant idiom in another language into a language where it's klunky, poorly-supported, and contrary to the grain of the language. It isn't elegant in JS just because it's elegant in some other language. It's exactly what it looks like: a klunky, choppy way to program in JS that requires the creation of a ton of functions that only a few outliers would normally think deserves its own function, making following this code require a lot of jumping around in the code base.

And that's assuming it is what it says it is, which, as near as I can tell, it isn't. If I'm reading this right, it doesn't seem to properly short-circuit on errors properly, rather doing a rather odd thing where it tries to pass the value along down the line, which is at the very least going to have performance consequences and almost certainly major correctness consequences as this scales up. It's actually not even an implementation of "monad", but a sort of chopped up version to try to avoid creating even more functions, which is what is really necessary to correctly implement the "monad" interface. In Haskell do notation, every single "<-" is actually an entirely new function, nested inside the previous one, so:

    do
        thing <- whatever1
        morething <- failableLogic arg thing
        things <- mapM stuff [thing:arg2]
        return head things

If "failableLogic arg thing" fails, that function ends up returning, and the next two lines "don't execute", that is, the nested functions don't ever get invoked. The "return head things" is actually a function nested in a function nested in a function nested in a function. (I may be off by one.) I think the core reason there's a lot of blog posts about how to "implement monadic stuff" in all kinds of other languages and no code in the wild that actually uses any of it is the requirement for all the nested functions. (You usually can't "unnest" them either due to the fact you're almost always closing over values from the previous functions.) It is astonishingly inconvenient in languages that don't have the requisite features and support, to the point you can fairly reliably guess that if someone has an implementation that isn't staggeringly inconvenient to use, they've missed something fundamental.

Even the languages that sorta kinda support this, don't, really. They encode specific bits of functionality vaguely inspired by monadic handling, but out of the Haskell family of languages I don't think I've yet seen a full, true implementation of "monad" in general that anyone uses.

(When writing "$LANGUAGE in $LANGUAGE" isn't adequate for a task, it's almost always the right answer to go get a new $LANGUAGE.)

  for {
    thing <- whatever1
    thing2 <- mightFail
  } yield (thing, thing2)

There’s all manner of creative ways to solve problems in code but if they aren’t idiomatic then, IMHO, they aren’t applicable. Code should be first and foremost understandable by humans and only incidentally for compilers.

I think this is something where it works well with language support (like Rust), but it seems really unidiomatic in JavaScript, and so it ends up hurting readability more than helping it. In a team context you would have to make a code style decision to handle things this way.

You're very polite. I'm going to be more frank.

Monads like this are very problematic in the JavaScript world. I say this as an F# programmer, and our community is not unfamiliar with Railway Oriented Programming (https://fsharpforfunandprofit.com/rop/)

Unlike F# or any other decent functional language, JavaScript doesn't have very good constructs to guide and ensure the programmer is using these constructs properly, let alone using alongside with existing error propagating constructs.

What happens when you mix these with promises, or RxJs, or something else?

My advice would to be avoid using constructs like this for general purpose error handling and use tried and true constructs for Exceptions, which should be exceptional.

Something like this isn't entirely useless, sometimes its useful to encode errors in an abstract type when the errors become an integral part of the problem domain. Sometimes errors aren't exceptional and you need a way to deal with them that's somewhat performant. Even if that's the case, you need to be careful with constructs like this because it's easy to use them wrong, which might lead to scenarios where errors aren't properly thrown and propagated.

I'm not saying to never use them. I'm just heeding you should tread carefully.

Here's a better formatted one: https://blog.logrocket.com/elegant-error-handling-with-the-j...

It's not even accidentally bad. They went through a significant amount of effort to make it a great deal worse than simple black text on a white background.

Also, the text is too big by default.

Your statement is true for throwing exceptions, however you cannot catch exceptions in pure way

Yup. Pretty sure the most referentially transparent function will stop if you unplug the power.

Imagine a signature like this:

function oneDividedByX(x: Double): Double

oneDividedByX(2) // 1/2

oneDividedByX(3) // 1/3

and so on.. Except with zero. With zero you get an exception, however nothing in function signature mentions about such result. You only expect a double

In Either case - it solves the problem, because the signature would be like this:

function oneDividedByX(x: Double): Either[ComputingError, Double]

As for throwing exceptions - it can be done in pure way, but catching exceptions cannot

I think the point is there is no inherent meaning. It is just two possible results. Could be an error, could just be another likely path. Will only be one of them, though.

TFA had so many parentheticals and explanatory comments on this that it would have been shorter if it used "Sad" and "Happy" instead. Of course, if brevity had been a goal there would also have been some inheritance...

The way I remember is that the Romans associated the left with bad things, with this ultimately making its way into English in the word "sinister" [1]

As this association was extended to left-handed people, its use nominally perpetuates an ancient slur, but I think we can put that aside.

[1] https://english.stackexchange.com/questions/39092/how-did-si...

> I constantly need to spend mental energy on remembering which is the Ok and which is the Error

Right is actually a synonym for Ok.. besides, Either is useful for _much_ more than error handling. That is exactly why I dislike Error for the left side; often it's just not an error.

The naming is totally mnemonic.

If all went well, the result is Right.

If something went awry, you can still examine what's Left.

A mistake easily corrected. They do convey the exact meaning well. It's the analogy that appeals to your intuition which is wrong.

    Either a b === a || b

Where `===` means equivalent to. This means that a value of the type can hold either the `a` or the `b`. In order to construct a value of this type you used the `Left` function to construct a value contain the value on the left side of the operator and Right for the other side.

They have no "semantics" otherwise. You could call them "Jib" and "Jab," and it'd amount to the same thing. Simply because you ascribe a particular meaning doesn't change their nature. Hence why Left and Right.

Now I do recommend, for readability's sake, ascribing an alias to this type if it aids your understanding of the code when you use it in a particular way that gives your code a certain meaning!

    const ChargeSuccess = Left
    const ChargeDeclined = Right

    const NormalDelivery = Left
    const FastTrack = Right

I remember it by thinking that Left (error state) has to be handled first. This forces developers to always think of the erroneous state first and foremost. And then define the Right (success state).

On the other hand, it may be easier to forget the error state if it were the second argument. As is often the case with Promises and JS developers.

To my mind the problem isn't so much having Either as using it as Result - which I agree was unfortunate. In the same way that fst and snd don't tell me much about a tuple.

At least there's a pun (right vs. left, right vs. wrong), which is probably why the pattern stuck, but I don't think that's actually sufficient justification.

The left one is always the error because the right is the right one.

They are named like this because you can use it for more than just errors, it just so happens that it's a good fit for errors. In fact, I wish Rust had named it Either, instead it's called Result (with Ok/Err variants). This is great for errors, but it leads to the creation of (https://crates.io/crates/either) because there are scenarios where you want Either and the Err/Ok name is too presumptuous.

A good way to remember which variant represents success in the case you're talking about an error is that Right is the "right" variant, Left is the "wrong" one.

Yes it's terrible naming. The more abstract the naming, the harder it is to reason about. Plus, JS/TS already have proper union types without a need for a construct like Either.

A better naming for 99% of cases is (like found in Elm)

type Result error value = Ok value | Err error

I did this a ton when building some mixed-sync/async stuff in TypeScript, and tend to use it (or something like it, depending on the language) for any situation that looks sufficiently similar. What are the downsides to this? Why isn't it more common? (or maybe it is, and I'm just not reading the right code to see it)