Different/simple ways to implement some_function() and some_function!() that raises exception

Questions / Help
,
1

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

2

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.

1 Like
3

Thank you al2o3cr. Yesterday I wrote approx. 10 functions that will be used a lot in different places or different apps (I guess I can call it library) and when I started using them I realized that approx. 6 of them need to be in bang version. To make my life easier I just created all 10 bang versions since it’s quicker / easier to write it once then add a bang version every time I feel I need it.

But I take your point - each time I’ll ask myself do I need it bang? Can I just use case and with statement or something like that…

4

Your simplification seems reasonable to me. Since you mentioned lines of code, you could easily just do the following, without (in my opinion) any loss of clarity:

# renaming raise_error_or_return_value_in_tuple/3 to bang/3
def do_something!(input, number) do
  bang(do_something(input, number))
end

I have not used it but there is also the bang library.

5

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.

1 Like
6

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.

3 Likes
7

@bang library is from my perspective overkill, this is not. This is awesome!

I haven’t done macros yet so I wouldn’t be able to write it. I think I’ll take it (I’ll try) to another level so it supports :error (not just tuple with :error) and exception attributes (KeyError, key: :my_key, term: "bla bla bla").

Thank you!

8

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
3 Likes
9

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.

3 Likes
10

I agree with everything you said, which is why I explained that I don’t consider this a good idea as it just introduces another layer of indirection. :slightly_smiling_face:

But I felt the discussion should at least talk about the possibility.

1 Like
11

This is actually a big deal - I’d probably end up with some functions with bang macro and with some without so at the end it’d be a mess…

I’m grateful that you showed some really good use case for macros. Thank you ;-).

12

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.

5 Likes
13

Yep, exactly what I do as well.