IMO FunctionClauseError is internal-facing, and ArgumentError is a better external facing exception for consumers of the API

yeah, I'd prefer a fallback raising an ArgumentError when its not an integer, or a clause at the top matching on non-integers not is_integer raising an ArgumentError

As is, you'll get neither when a map is passed as the second arg eh? Needs an inspect in the error message if that's the intention

IMO FunctionClauseError is internal-facing, and ArgumentError is a better external facing exception for consumers of the API

that's not currently a convention i see in elixir, and to zach's point would involve adding a whole lot of final function clauses and when not is_... to existing ones to become the convention. FunctionClauseError is normal and fine when passed a whacky arg (Enum.count_until([], :whoops), especially since the error includes the patterned heads.

We typically don’t raise argument errors when the value is outside the domain of the function. So if you pass a list as count, it should be a function clause error. Plus the type system can infer proper types in those cases, if you accept the argument and then raise, it cannot.

💚 💙 💜 💛 ❤️

Plus the type system can infer proper types in those cases, if you accept the argument and then raise, it cannot.

This is pretty interesting. Is there some way we could support this? What you're saying makes sense, but there are many cases when building libraries where we solve DX paper cuts with better error messages.

def function(integer, opts \\ [])

def function(integer, opts) when is_list(integer) do
  raise ArgumentError, "Looks like you tried to pass options in ..."
end

That is a bad/contrived example that maybe should just warrant a function clause error. I'm wondering if functions that literally do nothing but raise an argument error could be considered as non-accepted inputs?

In the end, I realized that you're right the type system just makes it not make sense. You'd get a warning at compile time and so should theoretically never hit the runtime error. It does make me think that there could be some light regression on DX in some ways because we can't "steer" type system error messaging, you just are going to have to decipher the signature or read the docs/examples. A part of me wonders if a function clause with a raise TypeError, .... could make sense, or some other way to improve DX of people as they code and are using commonly incorrect formulations of code could be devised.

Probably not worth the squeeze. Thanks for coming to my TED talk 😆