Understanding the advantages of "let it crash" term

[kelvinst]

Well, responding to the original @rower687 question, I have a tangible example of an advantage of the “let it crash” philosophy: if you take it to extreme levels, you would not put clauses matching all result on your cases anymore.

The argument for this is just what @sasajuric said:

@sasajuric

At the core of it all is the idea of failing fast. This is not something exclusive to Erlang, and I believe it’s generally a good practice. We want to fail as soon as something is off. By doing this, we ensure that the symptom and the cause are one and the same, which simplifies the problem analysis. By looking at the error log, we can tell both, what went wrong, as well as why.

Excerpting it a little bit: exceptions like CaseClauseError are better errors to get than unexpected values escaping out of your own code.

I’ve posted this (with an example) on another topic:

Your Elixir Tips Thread

Oh, one more thing! Apply the “let it fail” philosophy wherever you can! For example, instead of: case foo(bar) do {:ok, bar} -> {:ok, bar.foo} resp -> resp end Do no match all clause, and let it fail for unknown scenarios: case foo(bar) do {:ok, bar} -> {:ok, bar.foo} {:error, resp} -> {:error, resp} end Again, silly example, but what I mean is: exceptions like CaseClauseError are better errors to get than unexpected values escaping out of your own code, believe me.