You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! When adapting the Sqids spec to Elixir conventions, I found no “operational error” to return when decoding - for ex, decoding a string with characters unknown to the configured alphabet will just return an empty list instead.
However, decoding can still raise if you feed it a non-binary, or a binary that’s not UTF-8 encoded. These do not count as operational errors (in my intuition of Elixir convention) but rather as “you’re holding it wrong” cases, where non-bang versions of functions nevertheless raise.
I therefore considered: what if there is decode instead of decode!, returning only the unwrapped success, but then the spec or implementation change and errors need to be returned? - Breaking change.
So I chose decode!, even though it doesn’t raise on operational errors - because there are none - as it seemed less likely to break compatibility.
Reviewing my thinking, I speculate the purest implementation would have been a decode function that only returns {:ok, ids} …which could at a later version start returning {:error, _} if needed.
Would that be a breaking change? I say it would, or at least more so than an already raising function that starts raising on operational errors whereas it didn’t before.
I went into the weeds there. I hope my reasoning was clear, and I’m open to a new perspective on this, as I’ve debated myself in the past about bang-function semantics. I’ll leave this issue open for a while. Thanks for raising it! (No pun intended)
Why
decode!/2
does not have a public non-throwing counterpart?The text was updated successfully, but these errors were encountered: