OK: Elegant error handling for elixir pipelines. Version 1.0 released

Very concise syntax for tagged fluent builder statements!

def instance(identity_ib_gibs, dest_ib, opts) do
  {:ok, identity_ib_gibs}
  ~>> TB.plan("[src]", opts)
  ~>> TB.add_fork("fork1", dest_ib)
  ~>> TB.add_rel8("rel8_2_src", "[plan.src]", ["instance_of"])
  ~>> TB.yo
end

And I’m planning on more, slightly longer factory methods just like these and this helps clean things up very nicely. Thanks!

Thanks for the feedback. I haven’t really thought about the builder pattern in elixir, I normally have a great map I pass to a single function if need be but it’s certainly a nice usecase and one where you get to ensure that functions behave the way you want.

Version 0.2.0 released.

I will make a 1.0 release soon as there is almost no API to decide on. The one change that I think perhaps should be made is renaming the OK module to Ok so is follows mix patterns for capitalization?

I’d recommend Ok as well as it is common vernacular now. However, OK is correct as it is short for (what is considered by etymologists(sp?)) Oll Korrekt, a vernacular of “All Correct” popularized in 1840’s New York (told to me by google ^.^).

So, although I tend to use Ok myself, technically OK is correct.

Awesome tangential knowledge. I may well have to add some documentation to the effect of recording that.

Someone wrote a great article about railway programming in Elixir. They used the >>> operator but it’s quite similar!

Here’s the link: Railway Oriented Programming in Elixir

Nice finding.
I assume this is based on article Railway oriented programming from great F# blog http://fsharpforfunandprofit.com/

Robert Brown • 2 years ago
I too read this RoP article and made an Elixir implementation of it. You can find it here: https://github.com/rob-brown/M… Your implementation simulates the behavior described in the article.However, RoP is intended to be built using monads. By using monads, you can use the bind operation with more than just success/failure, ex. maybe monad and state monad.

Would you describe railway programming as a pattern or a technique.

I see that that article gives a bunch of examples on implementing the macros. My life would have been much easier if i had found that first.

Would you have a use for any of the other concepts, such as the tee. I haven’t noticed them missing from my code. I think it might be an 80/20 rule. ~>> gives the vast majority of the benefits and the rest are just minor improvements

Although I love the concept, I found some issues with the implementation in practice for user errors, which is where this pattern is intended to be used. In particular:

1. not all functions return the same shape.
   • one of my own functions that returned {:ok, :name, %metadata{}} which wouldn’t fit.
   • some of the Elixir functions I needed didn’t return an error tuple. Map.fetch/2 for example just returns :error.
2. Although it was nice to break free when an error happened, I found error handling unnecessarily difficult because rather than handling the :error in context, I was doing it somewhere down the line. Often this meant I had to reconstruct context in order to provide a meaningful message to the UI.

To resolve #1, I decided to change how it measured the results and tested either the result == :error || elem(result, 0) == :error, and any other result was just passed through. This worked better for me and allowed for the shapes to be different. It could be expanded to capture more errors, but it still assumes that it would know all error conditions.

Overall, after using it for a while, it felt more like I was using try/catch or GOTO for flow control, which I am not fond of. I found it to basically be just a prettier but less comprehensible/usable version of with.

I still love the idea of a flow chart for flow control, though!