Live data from Hacker News

New in Go 1.20: wrapping multiple errors

lukas.zapletalovi.com

1–10 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#2
Given the now two interfaces, Unwrap() error and Unwrap() []error I really wish they had just done only the latter since the beginning. Continuing to have and support the prior feels like a mistake somewhat permanently baked into the language.

I know it is easy to armchair second guess but one of the very first things I tried when they added wrapping a couple versions ago was wrapping multiple errors. I am reasonably certain the majority of the pre-native library error wrapping packages supported multiple errors as well. The desire seems reasonably obvious.

Re: New in Go 1.20: wrapping multiple errors

#3
Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release?

What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date formatting, lack of enums, implicit interfaces, ...) and Go repeats design mistakes that were recognized as mistakes decades ago (nil pointers), but all of that is happily overlooked in practice because huge codebases compile in three seconds, you don't have to argue about which formatter configuration to use, and everything from TLS to CSV is rolled into std without ever having to import a third-party repository.

Re: New in Go 1.20: wrapping multiple errors

#4
post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

I’m glad it’s not just me who is perplexed at some of the decisions made with golang.

This was a golden opportunity to implement some typical form of exception handling. Instead you have to bundle your errors together and then unwrap them (often using multiple methods to handle the cases of both a single error and a bundle of errors) and then still implement even more logic to walk the tree you made?

Re: New in Go 1.20: wrapping multiple errors

#6
post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

I feel a lot of that has to do with Googlers not daring to question the famous authors, and the same authors seem to have been asleep for the last three decades in terms of modern programming language developments. I geared up to learn Go one day, got the book and everything, and after just a few hours of trying to write and rewrite error-handling code, I was wondering how this ever got out of the Request for Proposal stage.

Oh, you have to manually chain your errors and no you don't get stack traces out of the box. If you want to to know where the error message is, I don't know, guess?

It's insane.

Exceptions happened precisely because manual error-handling was messy and did not scale, but suddenly it's The Way.

Re: New in Go 1.20: wrapping multiple errors

#7
post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

Go with Rust-style tagged unions would be a delight (and that would improve error and null handling in many ways)

Re: New in Go 1.20: wrapping multiple errors

#8
post #6
post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

I feel a lot of that has to do with Googlers not daring to question the famous authors, and the same authors seem to have been asleep for the last three decades in terms of modern programming language developments. I geared up to learn Go one day, got the book and everything, and after just a few hours of trying to write and rewrite error-handling code, I was wondering how this ever got out of the Request for Proposa…

You do get stack traces out of the box? Exceptions trigger stack traces, or you can PrintStack

Re: New in Go 1.20: wrapping multiple errors

#9
post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

> everything from TLS to CSV is rolled into std without ever having to import a third-party repository

And yet the std library is missing some basic data structures like Set.

Re: New in Go 1.20: wrapping multiple errors

#10
post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

For all that you have the JVM ecosystem with multiple better languages (including Java itself)
Post reply on HN