Better Error Handling

Monadic style or not, the `if err != nil return err` pattern destroys critical information for debugging. `try/catch` gives you a complete stacktrace. That stacktrace is often more valuable than the error message itself.

An advantage to the Monad approach is that it sugars to the try/catch approach and vice-versa (try/catch desugars to monads). JS Promises are also already "Either<reject, resolve>". In an async function you are writing try/catch, but it desugars to monadic code. You could write an alternative to a library like "neverthrow" that just wraps everything in a Promise and get free desugaring from the async and await keywords (including boundary conditions like auto-wrapping synchronous methods that throw into Promise rejections). You could similarly write everything by hand monadically/pseudo-monadically directly with `return Promise.reject(new Error())` and `return Promise.resolve(returnValue)` and everything just works with a lot of existing code and devs are quite familiar with Promise returns.

It might be nice for JS to have a more generic sounding/seeming "do-notation"/"computation expression" language than async/await, but it is pretty powerful as-is, and kind of interesting seeing people talk about writing Monadic JS error handling and ignoring the "built-in" one that now exists.

This is also where I see it as a false dichotomy between Monads and try/catch. One is already a projection of the other in existing languages today (JS Promise, C# Task, Python Future/Task sometimes), and that's probably only going to get deeper and in more languages. (It's also why I think Go being intentionally "anti-Monadic" feels like such a throwback to bad older languages.)

Moving from try:catch to errors as values was so refreshing. Same company, same developers, but suddenly people were actually _thinking_ of their errors. Proper debugging details and structured logging became default.

I assert that try:catch encourages lazy error handling leading to a worse debugging experience and longer mean time to problem discovery.

Nice thing about Monads in JS with tools like neverthrow is that you can create the Monad boundary where you like.

It becomes very similar to try-catch exception handling at the place you draw the boundary, then within the boundary it’s monad land.

If you haven’t wrapped it in a monad, chances are you wouldn’t have wrapped it in a try-catch either!

Don’t accept sloppy development practices regardless of what programming language you’re going to use.

Just FYI, the go linter has `errcheck`, which would catch your sloppy developer checkins: https://golangci-lint.run/usage/linters/#errcheck

> We live in a multitasking world, so our users can deal with out-of-disk and out-of-memory errors by deleting files, adding more storage, closing other (lower priority) processes, paging/swapping, and so on. So you can wait: maybe alert the user/operator that there is trouble but then wait for the trouble to clear.

That's a weird take. I've been working for multiple decades now with systems that have no UI to speak of; their end-users are barely aware that there's a whole system behind what they can see, and that's a good thing because they become aware of it when it causes them trouble.

I take from my mentor in programming this stance for many things, including error handling: the best solution to a problem is to avoid it. That's something everybody knows actually, but we can forget that when designing/programming because one has so many things to deal with and worry about. Making the thing barely work can be a challenge in itself.

For errors, this usually means: don't let them happen. E.g. avoid OOM by avoiding dynamic allocation as much as possible; statically pre-allocate everything, even if it means megabytes of unused reserved space. Don't design your serialization format with quotes around your keys just to allow "weird" key names, a feature that nobody will ever use and that creates opportunities for errors.

Of course it is not always possible, but don't miss the opportunity when it is.

> For a stupid-simple example: You can't even check if disk is going to be full!

Isn’t this addressed by preallocating data files in advance of writing application data? It’s pretty common practice for databases for both ensuring space and sometimes performance (by ensuring a contiguous extent allocation).

This. There are errors and states you cannot predict. As a grandchild comment says: It's easier to provide solutions than to list all the errors. Find your happy path and write code that steers you back on to it. The code will be shorter, less surprising, and actually describable. It's also testable because you treat whole classes of errors consistently so your error combinations count is smaller.

There is in fact a common strategy for dealing with those errors. Shut the process down. That relies on another strategy. Reliable persisted state. Best practice here is to use mechanisms that ensures that at every moment the persisted state is valid. Some databases can guarantee this. You can also write out the new state to a temp file and atomically replace the old state with the new one.

I guess I’ll ask, did you try using exceptions?

> We start with a clean implementation that satisfies requirements ... Now we add logging and error handling.

If error handling and logging isn't necessary to satisfy requirements, why bother with them at all?

Handlebars like on a bike, or like the templating language?

It’s only leaky if you do not consider failure cases to be as equally intrinsic to an interface’s definition as its happy-path return value :-)

If you squint hard enough, any potentially allocating function is fallible. This observation has motivated decades of pointless standards work defending against copy or initialization failure and is valuable to the people who participate in standardization for that reason alone.

For practitioners it serves mainly as a pointless gotcha. In safety critical domains the batteries that come with c++ are useless and so while they are right to observe this would be a major problem there they offer no real relief.

[dead]

Observability tools give you this (as long as it can be handled and isn't a straight up panic).

Severity in majority of library functions is undecidable, it’s decidable at the call site instead. That’s why language should be providing sugar to pick behaviour - exceptions (propagate as is, optionally decorate/wrap), refute (error value, result type), mute/predicate-like (use zero value, ie undefined in js/ts).

There's no universal taxonomy of "this error is retryable, this one non-recoverable"; it's context dependent.

As a boring example, I might write something that detects when a resource gets hosted, e.g. goes from 404 -> 200.

The best I imagine you can do is be able to easily group each error and handle them appropriately.

Well you don't usually want double retry loops, and sometimes that subscript error is because the subscript came from input.

What to do with an error depends on who catches it. That's probably why Python got it wrong and then Rust said worse is better

An interesting development in this direction is Clojure’s anomalies taxonomy: nine outcomes (two retriable, two maybe-retriable, five non-retriable; nine respective ways to fix)

See table here: https://github.com/cognitect-labs/anomalies

Yes, I stopped reading at:

> The most common approach is the traditional try/catch method.

Errors often come from the fact that we build on unreliable medium.

Lost packets, high latency, crashed disks, out of memory etc.

You can talk to your users sure but you need to handle this stuff at some level either way. Shit happens!