Error handling in TypeScript. How to avoid exceptions.

In this video, I want to talk about alternatives to #exceptions in #typescript. There are ways to make the #code more #resilient and easier to #maintain by implementing better #error #handling on both #backend and #frontend. Most importantly though, exploring new #programming languages will help you gain new perspectives and ideas.

[podobayka]

I couldn't figure out the purpose of using neverthrow or the idea behind this approach. There was no information about it in the project repository either. Then I came across your video, and everything immediately became clear. Thank you!

[egorgor]

Thanks for the video, completely agree on the topic. Just wanted to point out that there is no need to use a library. It's enough to return a discriminated union type like Response<T> = { type: 'error', reason: string } | { type: 'success', data: T }

[AmirLatypov]

Throw error have an advantage that it can go up by the functions stack. For example, imagine 5 levels of nested functions, and the deepest can throw an error. Without throwing errors we need to check for errors on the each level, even if these functions are trivial. With errors though, we can just catch an error on the controller, and return 500 with a message from the error itself.

[coder_one]

Have you had a chance to get acquainted with the "ts-belt" library? This is a library for TypeScript providing Option & Result types, but also other flavors from functional programming. And most interestingly, the source code of this library is written in Rescript! :)

[orterves]

Rust also has the ? syntactic sugar operator to clean up the code quite nicely, passing errors up to the caller and proceed otherwise - it'd be nice to have the same in TypeScript but at least the type checker can force you to handle the potential error before you can try to get the value

The real downside to this approach is making sure you try catch any possible sources of exceptions, they can throw a real spanner in the works when the rest of the code is using result to avoid them - this is why I think checked exceptions are excessively maligned and are in fact a beneficial feature for robust code

[xorlop]

I like the idea of Either/Result types, because it clearly separates what is happy and sad path. However, I am curious your thoughts of just returning original value type and an Error? For example, safeParseInt would return int | Error vs Result<string, Error>.

I have been littering code bases with this and it has proven useful, and I am actually not sure when it would be desired or wanted to return an Error type in the happy path, so I don’t see the benefit of separating the sad path out.

Is there other benefits to wrapping in Result type I don’t see?

[Its-InderjeetSinghGill]

I built a better version of this, currently testing in some of my production apps and soon will be public for everyone to use soon.

[purovenezolano]

Recommend you switch to `neverthrow` as `ts-results` is unmaintained