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

12 comments

#error-handling #function

17 1371 12

2020-08-18 23:45:06 UTC

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.

Post #6

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.

Post #12

al2o3cr

Couple thoughts on this:

it makes the definition of test! harder to find - for instance, simple searches for def test! won’t turn it up at all.
applying @doc and @spec to the generated function is possible but looks odd (since the name in @spec doesn’t appear explicitly in a def)
barring some advanced macro-fu, the data passed to raise has 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

Post #8

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.

Post #9

al2o3cr

I don’t see a problem with that - it’s readable, and should be a familiar idiom for future readers.

A better question: are you sure you need this much API flexibility? Providing bang and non-bang functions is important for libraries, but carefully consider if your internal APIs could be more opinionated.

Post #2

benhoven

Thank you Bluejay, It’d have to be bang(do_something(input, number)), ArithmeticError or even bang(do_something(input, number)), KeyError, key: :my_key, term: "bla bla bla" with the exception and exception attributes as as optional arguments.

I’m still considering it… case is simple and explicit. bang() would be shorter but maybe it’s just unnecessary complexity.

The bang library is very interesting. At least I’ll take a look how it works inside.

Post #5