[epolanski]

The biggest "issue" with exceptions is that they are not exceptions at all.

One of the authors of Stoplight [1] once said during a talk that actually in an http transaction so many things can be wrong (30 major causes in a simple GET http request alone can derive from parsing) that writing http clients or mock servers is actually about handling errors and exceptions and stopping to think about those as unhappy cases, happy cases are, if anything, exceptions.

He then pushed for a complete rewrite of their tools using fp-ts and treating exceptions and errors as normal (algebraic) data types which brought critical failures and bugs to basically 0.

https://github.com/stoplightio

[valenterry]

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.

[epolanski]

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.

[1]https://gcanti.github.io/fp-ts/modules/Either.ts.html#trycat...

[2]https://gcanti.github.io/fp-ts/modules/Either.ts.html#trycat...

[valenterry]

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.

[epolanski]

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.

[epolanski]

@valenterry (I can't reply further), you can do that:

https://codesandbox.io/s/wispy-shadow-7789p6?file=/src/index...

In whatever ways you want to complicate it (with exceptions, asynchronous operations, with or without Do syntax) you can easily do that in fp-ts.

[valenterry]

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!

[valenterry]

You can click on the timestamp of the post to reply next time ;)

[valenterry]

(edited)

That's actually not too bad!

[valenterry]

Essentially, I want do write things in the style of (pseudocode)

    do {
       result1 <- either1
       result2 <- either2
       result3 <- fooReturningEither(result1, resul2)
    } yield result1 + result3

and so on. This gets very noisy without syntactic sugar.

[monkpit]

Is there any post you know of documenting this in more detail? I’d be interested to read more.