Understand the “Let It Crash” Philosophy

We used Task.Supervisor to isolate a process crash, but it may seem strange that we didn’t prevent the crash by simply adding error handling in the send_email/1 function. In this particular case, we did so on purpose to simulate an unexpected exception. In practice, we should provide error handling when we expect an error to occur, and leave the rest to the supervisor as a last resort.

Error handling in Elixir

When discussing error handling for Elixir, the phrase “let it crash” is often used. As a result, some people assume that “let it crash” means that Erlang and Elixir developers don’t do any error handling, which is not the case. Pattern matching and the macro construct in Elixir make working with {:ok, result} and {:error, msg} tuples easy. This approach is widely used in the community. Elixir also has try and rescue to catch exceptions, similar to try and catch in other languages.

However, as much as we try, we know that errors can happen. This often leads to something called defensive programming. It describes the practice of relentlessly trying to cover every single possible scenario for failure, even when some scenarios are very unlikely to happen and not worth dealing with.

Defensive programming in Erlang and Elixir