String to integer tuple API

For 1. I disagree with you, I consider it perfectly elixiry. The function is for data that you know can be parsed as an integer. You should not use it for unknown inputs. The documentation is pretty clear

string must be the string representation of an integer. Otherwise, an ArgumentError will be raised. If you want to parse a string that may contain an ill-formatted integer, use Integer.parse/1 .

What makes Integer.parse explode? It should give you either a tuple of number and remainder or :error.

Ah, I see it raises if you give it an invalid base, not because you give it an invalid string input.

If there can be at least one digit be parsed to the given base, you’ll get {integer, rest}, :error otherwise, rasie should only happen if the base is invalid.

case Integer.parse(str) do
  {num, ""} -> {:ok, num}
  {_, rest} -> {:error, :unparsable}
  :error -> {:error, :unparsable}
end

I respect your opinion, but I would like to direct you to the official Elixir documentation, in specific to this part:

In Elixir, we avoid using try/rescue because we don’t use errors for control flow . We take errors literally: they are reserved for unexpected and/or exceptional situations.

Source: https://elixir-lang.org/getting-started/try-catch-and-rescue.html#errors

I am aware of this. My objective here is to find out if there is a parsing function in Elixir that doesn’t throw and always returns a tagged tupple. I understand this is not the case, correct?

There is none, but you can easily wrap yourself, as I have shown in my code example.

I believe you’re misunderstanding the intent of that paragraph. It is correct that errors are not used as control flow, and that’s why the function explicitly says “must be the string representation of an integer”. The paragraph supports this, you shouldn’t wrap String.to_integer in a try. That’s the intent of the paragraph, not that errors are not used at all. Rather they should be used for “unexpected and/or exceptional situations”, such as someone passing "hello" to String.to_integer. Just like it should raise if it is passed :potato.

Elixir consistently raises ArgumentError for invalid inputs in the cases where the input doesn’t make sense at all.

Another great example of this is of course Integer.parse, which accepts any string, because it’s made specifically for unknown string inputs, while it throws an ArgumentError if the base is incorrect.

Digging deeper into the Elixir source can be helpful here, where you’ll find lots of instances of raising ArgumentError (there are also other errors used regularly, like KeyError)

Will you really allow user to specify base? Or you will really use base over 36? In general almost all Elixir functions can throw when passed incorrect arguments. Do you also want to prevent situation when someone passes atom to Enum.reverse/1?

I have a related question.

(Well, I think it might be related; I’m a novice and everything’s possible. )

I see that Elixir’s naming conventions discuss the trailing-bang:

A trailing bang (exclamation mark) signifies a function or macro where failure cases raise an exception.

Many functions come in pairs, such as File.read/1 and File.read!/1 . File.read/1 will return a success or failure tuple, whereas File.read!/1 will return a plain value or else raise an exception…

So, in a parallel Elixir universe, could Integer.parse not exist and instead we’d have both String.to_integer and String.to_integer!?

EDIT: hmm, maybe that parallel universe would actually be a pain; I overlooked the fact that Integer.parse accounts for remainder_of_binary and String.to_integer doesn’t.