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)
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
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
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!
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 withthrowError
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?where
leave
terminates earlyI'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. MaybeCont
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 readersthen 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.