How should Aff users use exceptions and "error channel"?

[chexxor]

I see that Aff will implicitly try-catch some exceptions, later surfacing them in runAff as Error, but it's not clear to me the cases in which this should happen and the Aff-related functions and combinators that should do this.

Also, it's not clear to me what will appear in the Error value in runAff. Anything thrown from PS using throwError? Anything thrown from JS using throw? Anything that is passed to the error channel, for example, from JS FFI using an error callback?

Is Aff's "error channel" and thrown exceptions one-and-the-same?

Also, it's not clear to me what kind of things should be thrown and which I should manage in my app, for example by using ExceptT SomeError Aff a.

If I use ExceptT to manage them on my own, should I still be using Error, or should I use a regular PS data type, like NonEmptyList String?

If I use ExceptT to manage them on my own, I need to handle errors in two spots, runAff and when handling the ExceptT value which is async-returned from Aff: which one should I send these example errors to? OOM OS error, invalid user when connecting to SQL database, HTTP 500 status response, insufficient user permissions to access requested data, requested 1 record but 0 record found.

I found some prior discussion on this [1], but I couldn't figure out an answer to my question from that.

[1] #65

[natefaubion]

The primary reason Aff uses Error is because Eff uses error. Aff wraps any Eff directly provided by the user (via liftEff or makeAff) with a try/catch. That is, any exception that occurs from immediately invoking a user provided Eff will be caught and pushed through the error channel. The error channel exists because there would otherwise be no other way to propagate these exceptions. It's the same reason why node APIs have the function(err, res) { ... } signature for callbacks. You would use the error channel for the same reason you would use exceptions in Eff, which is hopefully "to not" 😄. Sometimes callback APIs genuinely propagate async exceptions, and you should use it in this case. The Error type is purposefully sparse in PS, so you can't effectively propagate information for control flow, only for exceptional failures.

For control-flow exceptions, I would currently advise one to use ExceptT, and otherwise ignore the Aff channel. It mainly exists to notify you when very bad things happen. I wouldn't advise anyone to use exceptions in Eff for anything more than that as well.

I do appreciate the desire for a one-stop-shop sort of thing for control-flow. I would love to make Aff polymorphic over some error type, but since Error based exceptions are unavoidable if we permit you to lift Effs into Aff, there has to be some way to deal with those.

One possibility is to not allow you to recover from underlying Errors at all. If we recommend you use Error as little as possible, why not just enforce that? We could perhaps extend the supervisor API (#132) to let you observe these truly exceptional exceptions, but otherwise you wouldn't be able to catch them and affect control flow. This has consequences for things like bracket though. The bracket cleanup actions still have to run in the case of exceptional exceptions, and the API lets you observe the exception that happened. I suppose it could take Either Error e as the exception type.

We could also potentially use something like Variant as well, where we go ahead and index Aff by an extensible sum of exceptions, where exception :: Error is an ever-present label in that sum.

[chexxor]

Ooooh, I totally forgot that try-catch doesn't work for JavaScript's callback-style async. That's a missing piece to the puzzle. https://www.joyent.com/node-js/production/design/errors

So the reason an Eff turned into an Aff must be wrapped in try-catch is to convert from synchronous exception-handling (try-catch) to asynchronous exception-handling (error in callback).

Thanks for the great answer, @natefaubion - it's most of the info I was missing.

I was a bit sad that Error is in a key position in Aff, but only because it limits its portability to other backends (whatever value that adds). If the recommendation is to try to avoid using that, I can totally ride that train. I usually prefer to handle errors in pure FP using Either e a, so I'll just go back to that. Because the error channel was there in Aff, and in such a prominent position and well-defined position, I was like, "let's use this thing" and started throwing all the errors into it, and I loved it because my return type looked so much cleaner, a vs Either Error a. 😅

I'll just handle that error at the lowest level, when the Aff enters my app, and change it into a better-typed error, if applicable. Can do that using Either e a and perhaps make that e a sum type and maybe tuple that with my business-defined errors.

[safareli]

btw if Aff was parameterized by error type it still can be instance of MonadEff (Aff Error) right? so why aren't we doing it?

[jdegoes]

The primary reason Aff uses Error is because Eff uses error. Aff wraps any Eff directly provided by the user (via liftEff or makeAff) with a try/catch. That is, any exception that occurs from immediately invoking a user provided Eff will be caught and pushed through the error channel. The error channel exists because there would otherwise be no other way to propagate these exceptions. It's the same reason why node APIs have the function(err, res) { ... } signature for callbacks. You would use the error channel for the same reason you would use exceptions in Eff, which is hopefully "to not" 😄. Sometimes callback APIs genuinely propagate async exceptions, and you should use it in this case. The Error type is purposefully sparse in PS, so you can't effectively propagate information for control flow, only for exceptional failures.

Here's how I am solving these problems in Scalaz 8 IO, but translated into PureScript and patterned after Aff:

data IO e a -- error type and value

-- Import async code:
makeIO :: forall a. (((Either Error a) -> Eff Unit) -> Eff Unit) -> IO Error a

-- Import sync code:
liftEff :: forall a. Eff a -> IO Error a

-- Catch exception:
attempt :: forall e1 e2 a. IO e1 a -> IO e2 (Either e1 a)

-- Throw exception:
fail :: forall e a. e -> IO e a

A few notes:

• IO becomes a bifunctor, and one can lmap over the error to change IO e1 a into IO e2 a, i.e. embed a smaller error into a larger one, or convert one error into another type.
• Interruption is handled with Error, so a fiber failing because of interruption is the same as a fiber failing because of runtime errors.
• No exceptions are ever caught except in the 2 "import FFI" functions (in this example, makeIO and liftEff).
• The concurrency model necessarily changes somewhat because of these types. For example, if you join a fiber, and that fiber is interrupted, it interrupts you, too. (It is quite interesting this semantic falls out of the types, as we spent some time discussing whether or not it was correct.)
• Error-less IO can be modeled as IO Void a or forall e. IO e a. They are equivalent. This lets you create functions which force their callers to handle all error types.

[chexxor]

So, it seems to me that idiomatic async JavaScript libs and PureScript libs use the "error channel" differently:

• JavaScript uses the error channel for anything at all, such as invalid arguments
• PureScript uses the error channel only for truly exceptional events, using Either on the success channel for expected errors

As-it-is, I think PureScript apps best use attempt anytime it uses an Aff-returning PureScript function, because that Aff could be wrapping a Node lib which uses that error channel all the time. That is, when a lib function returns an Aff, it's not clear whether that Aff behaves using JS-idiomatic async error handling (message on error channel) or PS-idiomatic async error handling ('Either e a`).

In light of that, I feel like this Aff library needs a function for converting from JS-idiomatic async errors to PS-idiomatic async errors. Something like these:

-- Similar to `makeAff`, but converts from JS-idiomatic error handling
-- to PS-idiomatic error handling.
makeAffFromJS ::
  forall eff a.
  ((Either Error a -> Eff eff Unit) -> Eff eff (Canceler eff))
  -> Aff eff (Either Error a)
makeAffFromJS = attempt <<< makeAff

makeExceptTAffFromJS ::
  forall eff a.
  ((Either Error a -> Eff eff Unit) -> Eff eff (Canceler eff))
  -> ExceptT Aff eff (Either Error a)
makeExceptTAffFromJS = ExceptT <<< attempt <<< makeAff

With these available and the Aff lib educating its users to rarely use the error channel and be sure to convert from JS-idiomatic style to PS-idiomatic style when wrapping JS libs, I will be more likely to use Aff in a "safe" way, that is, not letting me forget to catch JS-thrown errors in my app.

[natefaubion]

Initially I wanted something like liftEff :: forall e a. Eff (Either e a) -> Aff e a, which is where you get into the issue of what you do when an Error is raised.

Is it useful to recover from Error based exceptions at all though using the normal MonadError machinery? PureScript relegates exceptions anyway to the "out of necessity" bin, so I don't even know if liftEff :: forall a. Eff a -> Aff Error a is something that's useful. It would only catch runtime exceptions, and since runtime exceptions wouldn't be part of the error channel in general, I don't think we should even allow it. I would much prefer uniform handling of Error given that it still exists for interruptions, and so an Error thrown inside an Eff should be equivalent to an interrupt.

I definitely think this is something we should plan for given that we are going to have a breaking release anyway when we lose the effect indexing.

[natefaubion]

In the same way, if an exception occurs in makeAff, it should not use the error channel, it would be equivalent to an interrupt.

[safareli]

Have you considered this?

liftEff:: (Error -> e) -> Eff a -> Aff e a

So the first function will be used when error is raised in eff

[natefaubion]

That’s no different than lmap. Why not just use catchException to lift it If you want it to be caught?

[natefaubion]

A mapping from Error to e isn’t that useful in general because it doesn’t carry much useful information. I can’t think of a case in PS where I’ve tried to introspect a native Error type.

[hdgarrood]

Although much of this post follows from GHC’s implementation of IO and exceptions and therefore isn’t really relevant to us, I think there’s also a decent amount which is: https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell. In particular, this post argues (and I agree) that GHC’s point in the design space — similar to the current Aff — where there is one fixed exception type (kinda) is actually a good one, since pretty much any IO action can fail for one reason or another, and that having to find a way of unifying all the different types of errors from all the libraries you’re using would quickly become very tedious.

Personally I like how it is now - I think the current design makes a lot of sense from both the perspectives of an application using the FFI a lot, ie in terms of interop, as well as that of a pure PS application which doesn’t take much if any notice of the JS ecosystem.

As a data point Pulp does make quite a bit of use of Aff’s MonadError instance, both to handle exceptions thrown by JS code, eg reading files which might turn out not to exist (for which I needed to introspect an Error), as well as for aborting early with an error, eg if you’re trying to publish a package but it doesn’t have a licence.

[chexxor]

After reading your answer and discussion in Slack, it seems I still don't understand how the "error channel" is meant to be used and why you're leaning towards making it the right place to put "business decided" error values rather than only truly exceptional events (interrupts?). Still unclear to me why we can't separate the "business errors" channel out of Aff and into something like ExceptT.

Anyways, this issue was presuming there'd be a simple answer/recommendation, but it's not the case. I hope someone can figure it out and contribute docs to better specify these things and recommend how to do it. Until then, I'll do my best to never need to use the error channel, or just work on a "SimpleAff" :).

I heard that you'd like to make a proposal related to changing/better specifying Aff's error channel, so I'll wait for that to happen to discuss further.

Thanks for your time, @natefaubion!