Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.
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)
I do find it odd that relude exports ExceptT but not throwError, but maybe I'm missing something
what are your requirements?
if all your checks are "before anything can happen", then wouldn't you need it at all?
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
do you know for which aspects of ExceptT you're trying to find alternatives?
f = do
x <- someIOf1
whenLeft x (\err -> leave err)
y <- someIOf2
whenNothing y (leave NotFound)
where leave terminates early
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?
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
then I'd say that you're pretty safe with ExceptT! unless you want to throw exceptions :sweat_smile:
And by that do you mean the warning from http://hackage.haskell.org/package/mtl-2.2.2/docs/Control-Monad-Except.html ?
yes. are you unfamiliar?
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!
ah no, I just implicitly assumed that you wouldn't want to use the runtime system's untyped exception feature!
although if you are 100% certain that all your exceptions should end the program, there's probably nothing wrong with using them.