[waynesonfire]

i'm a huge fan of erlang and i'm familiar w/ this philosophy and tend to have a hard time w/ applying it. when i develop software, i read man pages for the functions i call. i intently study their return values and do my best to address whatever conditions i can at that moment. if i'm unable to handle the fault, i generate a message with the intent to add context to the error and let it bubble up. that context is important. it's _very_ beneficial when a failure does occur because i can quickly ascertain the root cause due to my diligence in annotating the _BAD_ path with context--all the way to the top of the function stack.

i've noticed that when erlang programs crash, the error message and stack trace is a WTF moment. i hate that. so yes, there are all these benefits when focusing on the happy path, but there are down sides, can we explorer those? once software is written, it's how the _BAD_ path is presented to maintainers that matters. this philosophy, in my current understanding, throws those people under the bus.