Erlang has a strong philosophy on this -- let your process (a microprocess inside Erlang, not the entire VM obviously) crash rather than pollute your code with

Erlang has a strong philosophy on this -- let your process (a microprocess inside Erlang, not the entire VM obviously) crash rather than pollute your code with needless endless crap... dozens of try catches just do log that an error happened... that is insane. Death to defensive programming which is a massive endless blackhole to throw developer resources down! Due to the supervisor / worker model of Erlang -- if you don't know how to explicitly handle an error -- YOU DON'T! You simply let the process crash! You be tight with your pattern matching (you can think of them like assertions) and you let Erlang do its thing. {expected_thing, 55, SomeVarToCapture} = function_call(..) If the function doesn't return something matching {expected, 55, ...} it blows up -- it crashes... and this is fine. Because in most cases you don't know how to fix that problem anyway! But, it doesn't have to Erlang has try/catch when you want it -- for those cases when you CAN handle an error, you do know what to do to fix it... which is the point -- when you can HANDLE the error, you do... else let it go SPLAT.