benhoven
Different/simple ways to implement some_function() and some_function!() that raises exception
Hi Everybody ;-),
Based on my understanding the proper Elixir way is to implement functions that return :ok or :error instead of raise exception. And then if there is a need you can implement a function with the same name + exclamation mark that you can use when you’re sure that the code should work and therefore if it doesn’t you want raise in that function to terminate the app (or process).
Recently I found myself in situation where I wanted to implement a lot of functions without and with exclamation mark.
Example:
defmodule MySuperCool.BigModule do
def do_something(some_input, some_number) when is_map(some_input) and is_integer(some_number) do
# stupid example
case some_input do
%{valid: true} -> {:ok, some_number}
_ -> :error
end
end
def do_something!(some_input, some_number) when is_map(some_input) and is_integer(some_number) do
case do_something(some_input, some_number) do
:error -> raise ArithmeticError
{:ok, out} -> out
end
end
I’m looking at the code realizing that I have a lot of functions like do_something! with case that returns / raise exception. In other words I’m repeating the same code again and again…
So I tried to create a helper and rewrite it like this:
defmodule MySuperCool.SomeHelpers do
def raise_error_or_return_value_in_tuple(result, exception \\ UndefinedFunctionError, exception_opts \\ [])
when is_atom(exception) and is_list(exception_opts) do
case result do
:error -> raise exception, exception_opts
{:ok, value} -> value
end
end
end
defmodule MySuperCool.BigModule do
import MySuperCool.SomeHelpers, only: [raise_error_or_return_value_in_tuple: 3]
# same as above
def do_something!(some_input, some_number) when is_map(some_input) and is_integer(some_number) do
some_input
|> do_something(some_number)
|> raise_error_or_return_value_in_tuple(ArithmeticError)
end
end
And as you can see I “simplified” 4 lines of case statement into 3 lines some_input |> function |> raise_or_return.
In my view the simplification doesn’t really simplify it…
Could you please tell me should I just continue with case statements in every question mark function?
Thank you.
Kind regards,
Ben
Marked As Solved
wolf4earth
I think there is some interesting thought here. I certainly have written my fair share of bang-functions using the case-approach. And while I have no objection in particular against it (it’s only 4 lines after all) this could be a nice little macro exercise.
Disclaimer: As @al2o3cr writes below, using this is probably not a good idea, as it’s a major layer of indirection which will make your codebase harder to reason about. Nevertheless it’s an interesting use-case for macros, so consider this an educational example rather than a production ready one.
defmodule Boom do
defmacro defbang({name, _meta, args}, raising: error) do
quote do
def unquote(:"#{name}!")(unquote_splicing(args)) do
case apply(__MODULE__, unquote(name), unquote(args)) do
{:ok, value} -> value
{:error, reason} -> raise unquote(error), reason
end
end
end
end
end
Which you could then use like this:
defmodule Test do
import Boom
def test(nil), do: {:error, "is nil"}
def test(val), do: {:ok, val}
defbang test(num), raising: ArgumentError
end
Test.test(42)
#=> {:ok, 42}
Test.test("test")
#=> {:ok, "test"}
Test.test(nil)
#=> {:error, "is nil"}
Test.test!(42)
#=> 42
Test.test!("test")
#=> "test"
Test.test!(nil)
#=> ** (ArgumentError) is nil
As mentioned before, I’m not saying that this is a good idea - after all it’s a probably unnecessary layer of indirection - but it’s possible.
Also Liked
shanesveller
I don’t think I’ve seen it specifically mentioned when I skimmed the thread, but I typically write functions that can raise as very thin wrappers around the versions that return either ok-tuples or error-tuples. It just calls the non-raising version directly, then unwraps the okay tuple or raises on an error tuple. Exceptions generally don’t need all of the context an error tuple might include, so it’s rare that I need to have two parallel, standalone function bodies, which need better test scrutiny.
al2o3cr
Couple thoughts on this:
- it makes the definition of
test!harder to find - for instance, simple searches fordef test!won’t turn it up at all. - applying
@docand@specto the generated function is possible but looks odd (since the name in@specdoesn’t appear explicitly in adef) - barring some advanced macro-fu, the data passed to
raisehas to be known at compile-time and so can’t include any information about the actual arguments that caused a failure - a future reader of this code will need to understand what the macro does to understand what
test!does, versus reading four lines of straightforward Elixir
LostKobrakai
Those are exactly the reasons, why I feel this is a place for copy/paste or an editor macro and not a code level abstraction.
Popular in Questions
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
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








