Heya,
I don’t fully understand the objection here, even for new comers.
Mind developping a bit more?
To me:
This is especially true in cases where you don’t generally expect an error case and if you do you want it to raise/crash.
- A function might as well return
valueand raise in case of errors instead of only returning{:ok, value}without ever returning{:error, reason}, especially since we have the pattern with the!functions.
This is great for new comers because then they can learn the pattern of!functions vs.{:ok, value} | {:error, reason}
I often thing about this bit of Joe Armstrong’s thesis
- The example from Joe Armstrong never really explain anything from the user experience (the users calling your application) point of view. I prefer bubbling up errors up to the “boundaries” of the application (web ui, cli, api, etc.) so then I can decide what to do instead of crashing in a deeply nested context functions and the user only ever seeing the live view refreshing the web page. I could rescue the error though it makes the code much harder to follow than bubbling up the error in the first place.
This is also great for new comers because now they are forced to think:!functions mean the error is not worth informing the end user and{:ok, value} | {:error, reason}means it may be worth letting the end users know what’s going on.
I personally realised that it’s much better for humans and AI agents the like to force them to think about the various error cases of their programs and have established pattern to reason about it (! vs. {:ok, value} | {:error, reason}).
