Away from Exceptions: Errors as Values
It&#x27;s good to see so much focus on errors. They are essential when trying to build resilient systems. But our approaches are still very immature.<p>First, to make it clear, this article appropriately points out that exceptions are still necessary and relevant. I disagree with some of the use-cases given, but it&#x27;s important to recognize that exceptions should still exist in programming languages. Joe Duffy&#x27;s article about Midori&#x27;s error model [0] is in my opinion the best reference to actually understand the difference between exceptions and errors and why it&#x27;s so important to get right. It&#x27;s a very good article, and it has been posted here before; if you are interested in error handling it&#x27;s a must read.<p>Now, about errors as values. Treating errors as values is practical, and in modern programming languages, relatively ergonomic. That said, we already have some other comments in the thread pointing out how sticking to just &quot;errors as values&quot; is often not enough (btw, the article uses Rust, not Go, but anyway...). And it&#x27;s also important to clarify this: errors are such an integral part of our programs, and have so much to do with flow control, that I don&#x27;t believe thinking about errors just as values is enough. Sure, they might be &quot;just values&quot; under the hood, but in all programming languages we see either optional results or syntax sugar to be able to handle errors more gracefully. And in most cases, we still feel it&#x27;s not enough (or it&#x27;s enough to be practical, but not to be pleasant in many cases). So we should keep the door open, and not pretend we have already solved errors.<p>Finally, the topic of errors is extremely deep and complex, and when you start introducing other factors like how to report the errors publicly to a non-technical user, maybe in different languages, or whether to log it or send it who knows where, whether to trace or not, how, how to deal with duplicates or similar errors... then you start realizing that we are far from a satisfying and complete model for error handling. We haven&#x27;t reached this part of the discussion yet.<p>For the moment, passing most errors as values is the relatively painless way that still allows us to customize errors to our needs. But there&#x27;s still a long way to go.<p>[0] <a href="http:&#x2F;&#x2F;joeduffyblog.com&#x2F;2016&#x2F;02&#x2F;07&#x2F;the-error-model&#x2F;" rel="nofollow">http:&#x2F;&#x2F;joeduffyblog.com&#x2F;2016&#x2F;02&#x2F;07&#x2F;the-error-model&#x2F;</a>