Ok, I think John was right about IO bifunctor..

Ok, I think John was right about IO bifunctor..

A while ago there a post on how IO in scalaz had both a F and an E to reflect the error type that is more specific than Throwable. Cat has MonadError and ApplicativeError that assumes the error is a Throwable. That has alot of implications all up and down the APIs. Just as F has to be everywhere, once you want to customize the error to be more specific than Throwable or not related to Throwable at all much like as described in https://typelevel.org/blog/2018/11/28/http4s-error-handling-mtl-2.html, you have to fix all the APIs all the way down.

That means the post http://degoes.net/articles/bifunctor-io from John was kind of right in my eyes. Once you do the work to be anything more specific, you might as well be explicit everywhere since one the flood gates open, that’s it. You can always be less specific.

I ran into this issue when creating some specialized scala HTTP client’s that have a wide variety of algebras and the “HTTP” layer needed customizations so that it propagated errors that were consistent with the upper “odata” protocol layer. While I could have faked it, I thought I would try to drive the types and error handling all the way down, and it took me awhile to work out the abstractions.

So now, with F[_]] already in my type parameters, it is joined by E. Which does not work well as I would rather have F[E,A].

Note there are thoughts to the contrary here.

Arguments for and against this design suggest that in the end, it may be that application specific needs motivate its usefulness. However, if it is useful in enough places, you may need this capability as a default in order to use it all situations. I have seen arguments against this design but I do not agree with degree of importance around the assumptions in the counter arguments or around the application types and runtime environments (JVM vs JS).

It is also possible that the bifunctor IO design becomes more viable when new scala capabilities are introduce, such has union types. It’s possible that we need a macro that takes a list of types and “subtracts” one from it e.g. to allow different layers to add/remove errors to a type more easily than today. Note that John’s ZIO uses concepts borrowed from Akka and supervisory hierarchies to help manage error hierarchies. Seems innovative at the toplevel at least.

Declaring Error Intent with Types - the important part of bifunctor IO

It’s clear that an API can lie. You could declare a IO[E,A] with an E = Nothing (fs2 uses Pure as the bottom) but still have that IO throw something you were not expecting that cause the IO to fail in an “unchecked way.” Because the failure was unexpected according to the type, its a defect that the programmer must resolve. It’s not a recoverable error.

Suppose you declare your IO to be IO[Nothing,A]. If there is a throw that you did not handle as a programmer then the run time system for ZIO will have an exit status of “failed” with a Cause of Unchecked. If we had handed the error inside our code and translated that to a A our type is good and we can return that as an ExitStatus of Succeeded. If the IO fails with another error E (remember this E is not in our IO[Nothing,A]), we may want to “fail” the IO with a Cause of Checked E. But since the IO type just mentioned is IO[Nothing,A], we can’t return an Checked[E].

So if your E=Nothing the only ExitStatus[Nothing,A] you can create is a Unchecked error, which has type Cause[Nothing], or an Interruption concept, which is also of type Cause[Nothing].

When we say “return a value” in the asynchronous case, we use the runtime system method unsafeRunAsync to run the IO:

trait RTS { 
  def unsafeRunAsync[E, A](io: IO[E, A])(k: (ExitResult[E, A]) ⇒ Unit): Unit
}

If the IO we are running is IO[Nothing,A] then our “callback” can only be a ExitResult[Nothing,A] => Unit. The presence of Nothing therefore indicates that the only way the IO can fail is by the IO being interrupted or an unchecked exception is thrown.

Contrast to Cats

In contrast, if we used cats IO[A]. We know that this IO can have an exception in it. But its quite possible that the IO has been constructed so that no Throwable will occur or that any Throwable is translated into an A. Even if the error handling had already attached a IO.recover the signature would still be IO[A]. The idea is that an E in IO can communicate more information about failure handling in your program better.

In cats, we could also just have everything bundled up under Throwable. If we have data that needs to be pattern matched out of the exception we could also use a well-known exception. In highly interactive programs, such as a web program, I’m finding that errors are quite common, either do to communication failures or data “state” errors (lots of unexpected statuses). So errors are much more common. It’s a bit easier to have that E be explicit.

Is this a real issue. To be honest, I ran into these lack of clarity (ability to reason) and confusion about what’s in that effect very quickly when writing code for a web app. I thought that for all the trouble I went through to use types more smartly, this was a gaping, awkward hole in place where I have alot of code–error handling.

PS

  • I put in a E into a library that I am writing and pulled it out. I did not have a true bifunctor IO design and tried to fake it but that did not work out well in the end so I’m back to the implied Throwable design. The exercise was worth it though.

  • I am playing with ZIO on github to understand the bifuctor IO value proposition.

Comments

Post a Comment

Popular posts from this blog

quick note on scala.js, react hooks, monix, auth

quick note on scala.js, react hooks, monix, auth Reactjs hooks finally came out of preview in a recent version of React. scalajs-reaction has had support for hooks since they were in preview. React hooks seem like the hot new thing but for me the question is, do hooks help improve your code by improving maintainability, time to market, TCO, etc.? Let’s take a look using authentication as an example and employ monix , a reactive observable framework that also builds on cats . We will assume we are building a SPA. Does it improve your code and make your application & development experience better? Auth Auth processing can be complex. Many react auth examples you find in blogs like to show how to use “react-routing” and “auth” as a switch that determines which routes are protected or unprotected. Protected routes show application specific data. Unprotected routes show login content . Based on storing a “User” object in the browser session/local storage, th...
Read more

zio environment and modules pattern: zio, scala.js, react, query management

zio environment and modules pattern: zio, scala.js, react, query management This blog covers a zio-based fetch design for scala.js, react web applications. It heavily uses the zio “environment” feature to help motivate a point of view on the modules pattern in effect systems. At the end, I summarize some thoughts on ergonomics and complexity. This blog assumes a basic knowledge of zio and react. scala.js is just like scala so you mostly already know scala.js. This blog is a follow-on to previous blogs: https://appddeevvmeanderings.blogspot.com/2019/10/scalajs-react-fetcher-hook_48.html and https://appddeevvmeanderings.blogspot.com/2019/11/scalajs-and-react-suspense.html . I have been keeping an eye on and culling ideas from typscript/javascript fetching libraries that address query management concerns. The formulation below incorporates some of those concerns but does not try to comprehensively duplicate well established javascript libraries. I only care about ...
Read more

attributes with react and typescript.md

If you use typescript with react you may wonder what the right signature is for your “properties” interface. Obviously, your component will have few to many specific properties that reflect your domain. However, you may wish to also provide for the ability to add other attributes, such as those valid for a div property. In other words, you want to extend your props interface with that of the properties from a div element. How do you do that? There are really two issues: How do you extend your props interfaces How do you filter the props once you receive them to just those that apply. Extend Your Prop Interface or Use Sum Types It’s not uncommon to see interface Props { className ? : string yourProp ? : number } with the idea of using it in class MyComponent extends React.Component<Props, any> somewhere. If your component will have an outer div, you may also pass in a react element so that its configurable. But let’s say your outer element is a div and you wan...
Read more