Unfortunately, even with fp-ts, typescript does not yet have the means to enable ergonomic handling of errors without exceptions. I hope they improve this in the future though.
As a daily fp-ts user I'm not sure I agree, you handle them with the appropriate data type: Either.
Exceptions are a path like any other, there's nothing really magical about those, you catch the functions that could throw and handle the fact they have thrown the error, which error, why?
There's two helpers for that in fp-ts [1][2] plus the obvious lazy and asynchronous counter parts in the TaskEither and ReaderTaskEither modules.
I think it's a matter of perspective. I tried to user Either, but without proper pattern matching and syntactic sugar for monadic operations, I didn't quite like it.
That being said, I think the authors did a great job to make it as good as possible given the limitations.
Could you show the limitations you're speaking of?
I know fp-ts very well and it does not have those limitations you're speaking of.
Either admits all of the functor, bifunctor, monad, apply, applicative and traversable instances in fp-ts (so do all the other bifunctors) so there's no shortage of combinators.
If you are still here: any resources on how to build those other things that you mentioned myself? For example, if I would like to combine either and reader into a single monad, how would that look like? Now I'm kinda thrilled!
Exceptions are a path like any other, there's nothing really magical about those, you catch the functions that could throw and handle the fact they have thrown the error, which error, why?
There's two helpers for that in fp-ts [1][2] plus the obvious lazy and asynchronous counter parts in the TaskEither and ReaderTaskEither modules.
[1]https://gcanti.github.io/fp-ts/modules/Either.ts.html#trycat...
[2]https://gcanti.github.io/fp-ts/modules/Either.ts.html#trycat...