Avoiding ExceptT - Haskell

Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.

Adam Flott

What are the alternatives to ExceptT (https://www.fpcomplete.com/blog/2017/06/readert-design-pattern/ doesn't list any)? I do like being able to short circuit with throwError and friends, however I'm open to changing how I do control flow for IO computations where one needs to do a bunch of checks before anything can happen (e.g. check env var exists, etc)

Haskell isn't usually a language known for C++-style design patterns. Here's one counter-example, showing how to structure your applications.
Adam Flott

I do find it odd that relude exports ExceptT but not throwError, but maybe I'm missing something

Torsten Schmits

what are your requirements?

Torsten Schmits

if all your checks are "before anything can happen", then wouldn't you need it at all?

Adam Flott

Breaking out of the computation at any point. I do a lot of IO and already using a ReaderT/StateT stack, looking for a good way to have a return (from imperative-land) like mechanism for terminating early

Torsten Schmits

do you know for which aspects of ExceptT you're trying to find alternatives?

Adam Flott
f = do
    x <- someIOf1
    whenLeft x (\err -> leave err)
    y <- someIOf2
    whenNothing y (leave NotFound)
   ....

where leave terminates early

Torsten Schmits

I'd say that ExceptT is such a basic encoding of this pattern that there is little that gives you the same semantics with a significantly different implementation. Maybe Cont can provide something similar, but it is vastly more powerful.

and downwards, there's using Either directly or just returning () if no output is expected.

Do you see a problem with ExceptT or are you just wondering?

Adam Flott

Wondering, I'm happy to use ExceptT just wanted more options/someone who's dived into the topic more to say "use this for x and y reasons". Ultimately, trying to find good ways to present code to imperative-based readers

Torsten Schmits

then I'd say that you're pretty safe with ExceptT! unless you want to throw exceptions :sweat_smile:

Torsten Schmits

yes. are you unfamiliar?

Adam Flott

Ah ok, then a quick glance at the source says why. My brain parses that as "don't throw exceptions from something named except(ion)" which causes confusion. But, naming is hard!

Torsten Schmits

ah no, I just implicitly assumed that you wouldn't want to use the runtime system's untyped exception feature!

Torsten Schmits

although if you are 100% certain that all your exceptions should end the program, there's probably nothing wrong with using them.