Error handling in TypeScript. How to avoid exceptions.

[@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!

[@BeyondTypeScript]

I'm glad it was helpful! The important thing it to understand the principle, the library you use is not that important. Heck, you can implement the Result type on your own too! ;)

[@podobayka]

@@BeyondTypeScript Yea! You are totally right

[@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 = { type: 'error', reason: string } | { type: 'success', data: T }

[@BeyondTypeScript]

Completely agree!

[@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. 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?

[@BeyondTypeScript]

Thank you for your comment! Generally speaking, for safeParseInt there are indeed just two outcomes - either int or Error (with only one possibility for sad path - 0). So, it's okay to return int | Error. However, the Result type help to turn a partial function (not defined for all inputs) into a total function (defined for all inputs), by returning a value of type Result instead of int (for example). Notice that the Result type takes two generics - Result and can be constructed in two ways - Ok or Err. However, the Error generic can hold another ADT for all possible outcomes (in more complex cases). For example, a file system operation can fail for a number of reasons - all of them can be defined as an ADT (by the way, same is true for the happy outcomes). This situation would be a bit cumbersome to describe without any differentiation mechanism - int | FileNotFound | BadPath | FileLocked | Whatever. Compare this to Result. On top of that, sometimes, there are cases where your function may return int | int - but which one is which? All in all, I'd say that it's a good practice to stick to a single code style - either throwing exceptions, or int | Error, or Result type. Mixing them will lead to confusion in the team. However, if I have a choice, I always use the Result type. I hope it all makes sense :)

[@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! :)

[@BeyondTypeScript]

I didn't know about this library, thank you for sharing! But as I read ts-belt, the first thing I thought about was Rescript's Belt :) I'll give it a go.

[@AndresJimenezS]

try a bit Effect ts ;)

[@BeyondTypeScript]

Oh, 100%. I've been keeping an eye on this for a long time.

[@purovenezolano14]

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

[@BeyondTypeScript]

Thank you for the suggestion! Indeed, there are lots of alternatives to `ts-results`.