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

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.

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…

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.

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.

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.

@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!

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

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.

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.

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

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 ;-).