[alexjplant]

> The reason is simple: Golangs stupidly verbose error handling forces you to constantly think about the unhappy paths.

> Exceptions are the opposite: people do whatever and have someone else deal with the fallout later. This leads to people not thinking about errors and then someone using catch(all)-> doNothing kind of "solutions".

Ha! One shop that I worked at early in my career considered such null checks (in .NET, a language with a VM that would throw instead of crashing if you attempted a null dereference) the height of software craftsmanship. They bragged about remembering to do it at critical junctures and made fun of other teams that didn't do it.

  if(resumeId != null)
  {
      this.parserFacade.process(resumeId);
  }

Brilliant! No exception, no problem! This was great - except it was slowly discovered that features were silently broken for months on end until users directly complained about them. Then things were still great because the manager declared that no error messages showed up anywhere, so nobody got scared, so nothing was wrong.

They were right in a sense: the same manager had hand-built a SOAP-based logging solution with a bespoke UI that required us to explicitly log everything instead of just dumping to the regular sink and having an aggregator consume it for later viewing in Splunk or otherwise. We only got to see stack traces by RDPing into the specific server and looking for them - we'd never have seen these exceptions regardless!