Very good design pattern to handle business logic exception. Yeah, those outcomes/exceptions/errors are from business logic, they are defined by developers. But what about, errors that are thrown from 3rd-party packages?

Example:

import {readSync} from 'fs'
...
const json = await readSync(pathToFile)

and somehow there is an exception throw from readSync via many reason (file not found, file corruption, some process delete it, ...). How will you handle this?

This is great! I just tried it out for my signup flow and it makes my code so neat.

Would you know a good way to integrate this with Zod or the like?

Why use Either instead of a discriminated union?

I just discovered this. Coming from a Scala background I really dislike the whole exception paradigm. Even Go (one of the most basic languages) shuns exceptions in favour of a primitive Either pattern.

Thanks so much for sharing!

Thanks for writing this! I agree, especially the first part about not (ab)using exceptions to model expected outcomes of a function/process.

Regarding the Either<Left,Right> approach. I'm not convinced. I can't find a compelling reason to prefer this over discriminated union types.

Perhaps you can think of an advantage?

Thanks again!

return;

Great Article, I consider myself to be somewhat experimented with Typescript, but I had never seen Either used this way. Thanks !