This is a basic tenet of erlang. The philosophy is that if the inputs are bad, don't try to handle it. Crash the process to isolate the issue from the rest of the system (and god forbid, your database). Erlang's supervisor trees will restart the process for you.
Well that was unexpected! It makes me curious about the Erlang way. Thanks for the reply.
One of the other comments mentions validating user inputs which makes sense and is an exception to my comment above.
For the most part though, my comment stands, and it is, indeed one of the more unique and charming aspects of erlang.
It depends on the scenario. Web services or user interfaces accepting user input should be validated. However, in deeper code, it is better to let the system throw an exception and let the client handle it. Otherwise, how would the client know the method failed? Also, it is easier to debug behavior if a system throws an exception, rather than hiding the error.
You should...at the inputs to your system. Check the data when it enters your control. After it enters your code it's almost always possible to statically ensure that the data meets your invariants (hopefully they're well documented). Thus, programming defensively at this point doesn't do anything but slow the system down by adding redundant checks.