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