Either because you dread 500 Error Messages or you’re on some kind of JSON kick
you find yourself writing this style of ruby code:
Why? Well because you don’t want to risk throwing a Ruby Exception when it
could cause a 500 Error Message for a user, and you want to be able to control
error messages from your Model. For example, the join method could return any
one of the following responses:
So what’s wrong with that? Well, there are a couple of things.
You introduced conditionals into your model and controller that are entirely
unnecessary. Conditionals are not the worst thing in the world, but they create
divergent code paths, they make your code harder to understand and harder to
test. If you can avoid them, it’s easier for the next programmer to figure out
what you had in mind.
You created an additional dependency between your model and controller code.
Dependencies lead to bad things. The more modular your code is the easier it is
to test and the more versatile it is. It’s easier to use modular code in
background jobs and other objects and functions.
Thirdly, and most importantly, you are replicating a perfectly good programming
concept known as Exceptions. Exceptions are a program’s way of saying:
something went wrong - something is not as it should be. Any they are great to
use because they are easy to read and they break the normal code flow, which is
what you would expect if something went wrong.
How do we fix this code? Simple: we use Exceptions.