How to handle errors at callsite vs app-wide? #341

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?

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.

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.

Thanks for your help!