Just because the function does not end with an exclamation mark it is not guaranteed that the function will not fail. If you provide the wrong data, it could either fail with FunctionClauseError (meaning you input does not pattern match or matches any guarded function), ArgumentError (like in this case) or Protocol.UndefinedError (the protocol X is not implemented for data type Y, or any other exception that the developer considered more appropriate to describe the failure.
eksperimental
al2o3cr
There are two main ways for the inputs to Integer.parse to be “wrong”:
-
the first argument doesn’t start with a valid digit in the selected base. This returns
:error -
the second argument is out-of-bounds, rendering the operation meaningless. This raises
ArgumentError
I see these as two different situations; in HTTP-status terms the former is a 4xx (“something is wrong with the request”) while the latter is a 5xx (“something is wrong with the server”).
3
jarlah
thanks for feedback. I come with multiple perspectives on this. Before i got a job signed for Elixir i tried to land another with Haskell. And i would have gotten it hadn’t it been for the other candidate had more experience (only two relevant candidates). Later i found out how stupid that would have been of a jump to go from general purpose to pure FP 
In addition I have worked for many years with Scala. And Java for even more years. So i know how to reason about exceptions and to handle “all corner cases”. Sometimes the latter would result in _ => Left "Something went horribly wrong" (using pseudo language here) . Other times explicit care is needed with a match arm for all different exceptions.
So the notion of completely failing the process just doesn’t feel right for me. I feel its an exit hatch. But, maybe this exit hatch is the way to solve things in Elixir and Erlang? Do i get benefits over failing the process versus handling the errors? I have worked with Actors in Scala with the akka framework, and actors dying is not a problem.
But maybe this now borderlines into needing its own thread? For ex “Whats the benefits on failing a process versus handling exceptions explicitly?” It has do with more than just the tediousness of error handling. The language syntax in Elixir doesnt make it hard to code it up or even abstract out an error handler object.
0
rvirding
Creator of Erlang
I think there are errors and there are errors. They can be of different types and reasons.
For example you may be using input that has come from “outside” then it would be reasonable to check the data and if it has bad format then return some value saying it was bad and please resend it in the correct format.
If however the error is due to internal errors in your code (yes they do happen 
) then maybe the only sensible thing to do is to let it crash, i.e. crash that process and let the system clean up around so it can keep going. Checking error values everywhere and at all levels will result in really messy and error prone code.
There are errors and there are errors and there is no one way which is best to handle them all.
10
LostKobrakai
One distinction nobody seems to have talked about yet is also the fact that there are independend processes on the beam. Where in other languages one might need to wrap things in layers of “don’t let errors out” on the beam you often just spawn another process to do the work and just see if it responds with something useful or crashes.
3
christhekeele
I think phoenix has nice facilities for this: fill out the error handler, and in controller processing it will 1) return the correct response to the user’s request and 2) then continue to propagate the error.
More generally, your callers should be expected to be good citizens of your API and interpret the error codes accordingly and back off. Then you only need handle poor citizens the same way you do others: with a rate-limiting policy.
1
gregvaughn
Yes. This. We don’t talk about this often enough. Once someone gets truly comfortable with lightweight processes with fault tolerance, then processes because a design technique. They can be used to limit the “blast radius” of an error. On a prior project I worked on we had a sort of batch job we did on behalf of our customers. We didn’t really need concurrency, but we launched each customer’s data in a separate process. This way, just in case one customer had bad/invalid/unexpected data/errors, it wouldn’t prevent all the subsequent customers’ data from being processed.
6
dimitarvp
By the mere virtue of using Phoenix, you are some 5 to 15 coding lines away from having it return HTTP 400, 422 or whatever else according to your specs when input is mis-shapen. It’s really easy to do.
I agree that when it comes to web endpoints we should make a very best effort to not just crash with an HTTP 500. In my work I return a lot of HTTP 400s plus appropriate validation error messages.
That being said, some errors should be left to bubble up so they can pop in our monitoring systems, and then we can investigate. Would it be useful to have super defensive code that issues a warning buried somewhere: “Integer.parse has been called with base 47”? IMO it would be more noticeable if we deliberately let this crash so we can get visibility of the problem and see if we can make the calling code stop doing stupid crap – or should we really add the super defensive code.
Like with all things, it’s a balance. Don’t get overly paranoid. Put guards around DB operations and 3rd party APIs, absolutely; but you can’t recover from a situation where somebody wants to parse an integer with a base 47.
2