How to handle errors at callsite vs app-wide?

[seanhess]

I've been definiing custom effects as described in Effectful.Dispatch.Dynamic

My application has a large runner which adds all the effects, then in my functions, I rely only on the effect. If I understand correctly, this is all 100% by-the-book: My app has a bunch of capabilities, and individual functions only depend on the effects they need.

  data FileSystem :: Effect where
    ReadFile  :: FilePath -> FileSystem m String

 runFileSystemIO
   :: (IOE :> es, Error FsError :> es)

runApp :: Eff (SomethingElse : FileSystem : Error FsError : es) a -> Eff es a
runApp = runErrorNoCallstackWith @FsError catchLogAndThrowError . runFileSystem . runSomethingElse

example :: FileSystem :> es => Eff es ()
example = doSomething <<= send $ ReadFile "somefile.txt

However, sometimes I need to handle errors in a function, at the callsite where the effect is used. Perhaps I want to retry reading the file if it fails, or do something else. This doesn't seem possible. runError doesn't work, because the error effect is used inside the runner for FileSystem.

-- this does not work
example :: FileSystem :> es => Eff es ()
example = do
  res <- runErrorNoCallstack @FsError $ send $ ReadFile "somefile.txt
  case res of
    Left err -> putStrLn "do something custom with the error"
    Right contents -> putStrLn "handle file normally"

The only way I can think of to get this to work would be to re-run the file-system effect:

-- `es` contains FileSystem already
example :: (IOE :> es) => Eff es ()
example = do
  res <- runErrorNoCallstack @FsError $ runFileSystem $ send $ ReadFile "somefile.txt
  case res of
    Left err -> _
    Right contents -> _

But I have to pass IOE around everywhere now! I lose all the benefits of isolating individual effects. My handler depends on all the global effects, like IOE. It gets worse if the effect in question requires several pieces of global app config, etc.

Standard exceptions handle this use-case quite gracefully: I can catch errors globally in some app runner, but if I catch them locally, I can handle them. But an effect that can throw Exceptions doesn't immediately tell you which errors can occur, or force you to handle them.

What is the right way to do this?

[arybczak]

Did you have a look at #149? In particular, #149 (comment) might be what you're looking for.

[seanhess]

I did look at #149 earlier, but wasn't sure if it was what I needed. If I understand correctly, using that approach will require the Error effect to be in scope when you run the action, meaning you can run it right before calling. But if you don't run the error right before calling, it'll still give you a missing handler compiler error if you forget to handle it at the top-level. Is that right?

I'm also asking about best practices. I suppose the "normal" way custom effects use errors (per the basic example) works well for global handlers or for effects you can re-run inline. But I would think my use case would be very common. It's surprising to need fancy unlifting. Is there a better way to structure my app, or the interface of my effects, to make things smoother?

[seanhess]

Is the use FsError in the example an anit-pattern? Everything is much more straightforward if I use Exceptions and MonadThrow instead.

I think the FileSystem example is perfect to stage this question: Is catching exceptions and wrapping them in FsError a good idea for application-level effects? Or does it make sense to let the Exception system propogate as normal? FileSystem isn't enumerating a limited number of failure states, it's saying: "I can fail for a bunch of unknown reasons". As Snoyman argues here that's always true of IOE-like things.

[arybczak]

But if you don't run the error right before calling, it'll still give you a missing handler compiler error if you forget to handle it at the top-level. Is that right?

You simply won't be able to run the effect operation without the Error effect in scope, so yes.

I think the FileSystem example is perfect to stage this question: Is catching exceptions and wrapping them in FsError a good idea for application-level effects?

Unfortunately there's no clear recipe, so it depends. Usage of checked vs unchecked exceptions is IMO a balancing act that depends on what your goals are and what you're comfortable with.

[seanhess]

Thanks for your help!