Error Handling in Zig
I find this to be a good example where a language with well defined &quot;foundations&quot; can really shine.<p>If a programming language supports union types and type inference then there is no need for such a &quot;special&quot; language feature as described here. The return type will simply have the form &quot;goodresult | error&quot; and the compiler will infer it based on the function-body alone.<p>At the same time, the following problem of zig is automatically a non-issue:<p>&gt; A serious challenge with Zig&#x27;s simple approach to errors that our errors are nothing more than enum values.<p>If the result is &quot;goodresult | error&quot; then I can choose of what type &quot;error&quot; is and I&#x27;m not bound to any predefined types that the language forces upon me.<p>In fact, the article then shows how to work around the issue with a tagged union. The problem is that this creates another issue: the composition of different error types.<p>E.g. having function foo calling bar and baz and bar can fail with barError and baz can fail with bazError. Then, without having to do anything, the compiler should infer that foo&#x27;s return type should be &quot;goodresult | barError | bazError&quot;. This won&#x27;t work if tagged unions are used like in the example - they will have to be mapped by hand all the time, creating a lot of noise.<p>While Zig&#x27;s errorhandling is not bad and miles above Go&#x27;s, it makes me sad to see that we still lack ergonomy of errorhandling in so many languages despite knowing pretty much all of the language-features that are necessary to make it much easier.