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)

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.

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?