What's the right way of doing error handling?

[eddiemundo]

effectful allows us to do stuff like

data MyEffect :: Effect where
  MyOp1 :: Int -> MyEffect m Int
  MyOp2 :: Int -> MyEffect m Int

data MyError1 = MyError1
data MyError2 = MyError2

runMyEffect :: (Error MyError1 :> es, Error MyError2 :> es) => Eff (MyEffect : es) a -> Eff es a
runMyEffect  = interpret $ \_ -> \case
  MyOp1 _ -> throwError MyError1
  MyOp2 _ -> throwError MyError2

myComputation :: (MyEffect :> es) => Eff es Int
myComputation = do
  myOp1
  myOp2
  
main :: IO ()
main = do
  nestedEithers <- myComputation
    & runMyEffect
    & runError @MyError1
    & runError @MyError2
    & runEff
  case nestedEither of
    -- record errors and throw for each left?

Using catchError doesn't remove the constraint so not sure how to properly use that either.

Do we just create an interpreter like

runMyErrors :: Eff (Error MyError1 : Error MyError2 : es) a -> Eff es a
runMyErrors action = 
  result <- action
    & runError @MyError1
    & runError @MyError2
  case result of
    Left e -> error e
    Right (Left e) -> error e
    Right (Right a) -> pure a

but that seems kinda unwieldy.

The other issue is that let's say that the interpreter holds mutable state then if you want to "materialize" the error you need to first call the interpreter with the mutable state, then call runError

blah = do
  -- I want my error
  result <- myComputation
    & runMyEffect mvar
    & runError @MyError1
  case result of
    Left myError1 -> doSomething
    Right a -> doSomethingElse

This kind of means that you need your mutable state in scope whenever you want to look at an error...

So is the right way something more traditional looking?

data MyEffect :: Effect where
  MyOp1 :: Int -> MyEffect m (Either MyError1 Int)
  MyOp2 :: Int -> MyEffect m (Either MyError2 Int)

and then you can decide after calling MyOp1 or MyOp2 to throwError and short circuit at those call sites, and then if you want to handle those errors else later you can runError?

[dark-ether]

sorry i haven't understood your problem, but allow me to guess, you complained that catchError doesn't remove the constraint maybe you want to use reinterpret to introduce internal effects?

[eddiemundo]

I think I was asking if there was a way not to use Either e a in the effect operations and still do a purely checked exception style. So like

data FileSystem :: Effect where
  ReadFile :: Name -> FileSystem m Text

since ReadFile can fail the interpreter (from docs) might be like

runFileSystemIO
   :: (IOE :> es, Error FsError :> es)
   => Eff (FileSystem : es) a
   -> Eff es a
 runFileSystemIO = interpret $ \_ -> \case
   ReadFile path           -> adapt $ IO.readFile path
   where
     adapt m = liftIO m `catch` \(e::IOException) -> throwError . FsError $ show e

so the exception is converted to a FsError. Then when we do the interpretation

action
  & runFileSystemIO
  & runError @FsError
  & runEff

we have access to what the error was only after discharging the FileSystem then FsError effect. This means if the caller of readFile wants to handle the error, they have to run the interpreters first. They could run catchError but then eventually runError @FsError still has to be handled even though it was already caught which I don't like.

So it seems like the only way of having the caller be able to handle the error without running the FileSystem and Error FsError interpreters is to change the effect operations to

data FileSystem :: Effect where
  ReadFile :: Name -> FileSystem m (Either FsError Text)

and the interpreter to

runFileSystemIO
   :: (IOE :> es)
   => Eff (FileSystem : es) a
   -> Eff es a
 runFileSystemIO = interpret $ \_ -> \case
   ReadFile path           -> adapt $ IO.readFile path
   where
     adapt m = liftIO m `catch` \(e::IOException) -> pure $ Left $ FsError $ show e

I'd like to also have the errors be more fine grained so then maybe I'd have FileSystem look like

data FileSystem :: Effect where
  ReadFile :: Name -> FileSystem m (Either FsReadError Text)
  WriteFile :: Name -> FileSystem m (Either FsWriteError Text)

I also want to have the option to handle these errors now or later so it seems I need to write helper functions...

readFile :: (HasCallStack, FileSystem :> es, Error FsReadError) => Name -> Eff es Text
readFile path = do
  result <- send (ReadFile path)
  eitherToError result

writeFile :: (HasCallStack, FileSystem :> es, Error FsWriteError) => Name -> Eff es Text
writeFile path content = do
  result <- send (WriteFile path content)
  eitherToError result

then I can runError @FsReadError if I feel like handling FsReadError and not have to see it later when running FileSystem.

I was just wondering if this is a good idea. I tried it the other way by just having the errors effects pop out when running the FileSystem interpreter and it didn't seem good. I have that running in production lol. Kinda works in a web server setting if most errors you can't recover from, but in general seems bad because whether an error is handle-able is dependent on domain/context and so it seems more flexible is to have the effect operations return the error.

[the-dr-lazy]

Think basically nothing is wrong with it. If the domain logic of the effect should represent an error, it should be there. Though personally don't like to write those helper functions and just use something like fromEitherM on the caller site if it don't want to handle the error.

[arybczak]

For the record, an alternative design can be

data FileSystem :: Effect where
  ReadFile :: Error FsReadError :> es => Name -> FileSystem (Eff es) Text
  WriteFile :: Error FsWriteError :> es => Name -> FileSystem (Eff es) Text

then the readFile and writeFile generated by makeEffect (or written by hand) will have type signatures and behavior like the helper functions you've written @eddiemundo.

[mkleczek]

I think this would be a very convenient addition to the API: #152

[arybczak]

@eddiemundo if you do what I did in #149 (reply in thread), then handlers will look a bit different. Here's a complete example with the modified FileSystem effect from the introduction of Effectful.Dispatch.Dynamic:

import Control.Exception
import qualified Control.Monad.Catch as C
import qualified Data.Map.Strict as M
import qualified System.IO as IO

import Effectful
import Effectful.Dispatch.Dynamic
import Effectful.Error.Static
import Effectful.State.Static.Local

----------------------------------------
-- Errors

newtype FsReadError = FsReadError String
  deriving stock Show
  deriving anyclass Exception
newtype FsWriteError = FsWriteError String
  deriving stock Show
  deriving anyclass Exception

----------------------------------------
-- Effect

data FileSystem :: Effect where
  ReadFile  :: Error FsReadError :> es => FilePath -> FileSystem (Eff es) String
  WriteFile :: Error FsWriteError :> es => FilePath -> String -> FileSystem (Eff es) ()
type instance DispatchOf FileSystem = Dynamic

readFile
  :: (Error FsReadError :> es, FileSystem :> es)
  => FilePath
  -> Eff es String
readFile path = send (ReadFile path)

writeFile
  :: (Error FsWriteError :> es, FileSystem :> es)
  => FilePath
  -> String
  -> Eff es ()
writeFile path content = send (WriteFile path content)

----------------------------------------
-- Handlers

runFileSystemIO
  :: IOE :> es
  => Eff (FileSystem : es) a
  -> Eff es a
runFileSystemIO = interpret $ \env -> \case
  ReadFile path           -> adapt env FsReadError  $ IO.readFile path
  WriteFile path contents -> adapt env FsWriteError $ IO.writeFile path contents
  where
    adapt env errCon m = liftIO m `C.catch` \(e::IOException) -> do
      -- The error effect is in scope only in the local environment.
      localSeqUnlift env $ \unlift -> unlift . throwError . errCon $ show e

runFileSystemPure
  :: M.Map FilePath String
  -> Eff (FileSystem : es) a
  -> Eff es a
runFileSystemPure fs0 = reinterpret (evalState fs0) $ \env -> \case
  ReadFile path -> gets (M.lookup path) >>= \case
    Just contents -> pure contents
    Nothing       -> localSeqUnlift env $ \unlift -> do
      unlift . throwError . FsReadError $ "File not found: " ++ show path
  WriteFile path contents -> modify $ M.insert path contents

Now you don't need the Error effect to be in scope when you run the FileSystem effect, only when you're calling particular operations.

I'll add this as an alternative design to haddock when I have a bit of time since people seem to not be aware of the trick of substituting m in the effect definition with Eff es and putting additional constraints on es for specific operations.

[eddiemundo]

I actually did try putting Error FsReadError :> es and FileSystem (Eff es) String in the effect operations individually but I did not know to do the localSeqUnlift which is cool. Now the ergonomics seem pretty sweet with this and a handleError that runs the error effect.

I guess the main difference between what the-dr-lazy mentioned, is that the default goes the other way. The caller decides whether to handle, instead of deciding whether to rethrow.

[jerbaroo]

Given a function child with an Error ChildError constraint, and a calling function parent with a different error constraint Error ParentError. As a newcomer to the effectful library I am wondering what is a neat/concise way for the caller to handle the ChildError and lift it into it's own error type.

Here is my attempt, I am just not a fan of the additional type applications at the call site. That stem from the type-level list of effects, having possibly more than one Error.

child :: (Error ChildError :> es) => Int -> Eff es String

parent :: (Error ParentError :> es) => FilePath -> Eff es String
parent foo = do
  x <- bar foo
  child x & liftError @ChildError @ParentError
  blah

liftError
  :: forall childError parentError es a
  . (Error parentError :> es, From childError parentError, Show parentError)
  => Eff (Error childError : es) a
  -> Eff es a
liftError =
  runErrorNoCallStack >=> fromEitherM
    (throwError @parentError . from)

[arybczak]

Did you try effectful-plugin? It will help a lot with not needing type applications if you're willing to go this route.

[jerbaroo]

Thank you, works perfectly