Crowdhailer
Has the `with` construct replaced the need for error handling in pipelines
Last year I wrote a library for error handling in elixir pipelines OK.
There were several discussions around this topic in the google group and I was certainly not the only one to suggest a solution like this.
The idea is that the pipeline continues if the return value is {:ok, something} and stops and returns if the return value is {:error, reason}. It allows you to write code like the sample below.
def get_employee_data(file, name) do
{:ok, file}
~>> &File.read/1
~>> &Poison.decode/1
~>> &Dict.fetch(&1, name)
end
I find that I still use this myself, but that perhaps I should be using the with construct more.
My question is has with reduced your use of pipelines in general?
This would seam note worthy as the pipes are of a feature with new developers are very keen on.
Most Liked
OvermindDL1
Heh, I link your ‘ok’ library at times as an example of doing things. For context there are other libraries for this style of piping and with style error handling. There is happy (my personal favorite for the general case, entirely replaces with via happy_path, but with extra features like a default else case for things not handled in the main else area and such, and works on older Elixir’s), ok_jose, which is kind of like your “ok” except instead of adding a new inline operator it uses the normal pipe operator, you just have to finish your pipeline with |> ok, which thanks to how it compiles all the entire previous pipeline gets passed in to ok as a macro to do its work, and lastly the new-comer (just released) exceptional, which has 3 different ways of error handling, the usual tagged tuples like ok/ok_jose/happy/with support for error handling, exceptional handling, and a new method of returning the wanted value or returning an exception object (not raising it, returning it) to handle the successful/error cases, an interesting looking style I need to look closer at.
Now I barely use with itself because I use the default else case of happy_path/happy_path! excessively (great for handling generic errors in phoenix like bad params, bad database lookup, etc… etc…), but considering happy_path and with do the same kind of use-case in an almost identical way then I do not really ever use things like ok/ok_jose/etc but instead I do pattern match out the tuple, this is because I have my default error case handle almost everything (case-specific things are handled via a case branch, that then falls back to the generic error handler) and returning a message saying the user passed a bad argument or there is no row with that ID or whatever is a nicer message.
Crowdhailer
So after this discussion I have decided to play with this library again. There is now proper documentation available.
OvermindDL1
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









