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.

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.

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”).

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.

A lot of times I use the ! variants if an error is considered unexpected behaviour. Then I want my app to crash, I don’t care about handling those cases. This makes code easier to read as far as I’m concerned.

Consider having a method where you retrieve a database records. Sometimes you want to be able to handle the fact the record is not there. But somethimes you know it is there; and if not the app can go into oblivion.

Furthermore, this can help with typespecs in your app, if you want to go down the ‘happy’ path. In our projects we make a distinction between errors that can occur and should be handled and unexpected behaviour where there is no sensible thing to do anyway. I hope my reply makes a bit of sense.