Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New in Go 1.20: wrapping multiple errors

lukas.zapletalovi.com

Post reply on HN
Print view View original

71–80 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#71

Post by sidlls »

candiddevmike wrote: post #5

I still don't see a benefit with this over custom error types. Having a huge switch statement to determine the HTTP response code seems really inefficient vs just doing errors.As and getting the response code directly.

It is not efficient, except at that one point in time you write the code.

This is `errors.As`: https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/.... It uses reflection and type assertions and itself contains error checking (e.g. to validate that the arguments are actually error interfaces).

It looks efficient in your code because the call is compact, but this is not even close to efficient, and especially not as efficient as a switch statement.

Re: New in Go 1.20: wrapping multiple errors

#72

Post by lmz »

XorNot wrote: post #53
thequux wrote: post #34

Earlier quoted context omitted.

Exceptions reflect the realization that the proper place to handle an error is generally not where the error itself occurs. The problem with exceptions (and error returns, for that matter) is that the best place to handle an error is also not the same as the best place to decide how to handle the error. So far, the only programming environment I've seen that makes a three-way distinction between raising, recovering,…

> the best place to handle an error is also not the same as the best place to decide how to handle the error. I'm not sure I follow the distinction here, or at least why it would be important? i.e. if I parse "decide how to handle the error" as catching the exception, where I handle it is surely basically anywhere since I'm not restricted in calling into other code to do so.

Common Lisp exceptions are resumable which is the main difference between it and more common languages like Java and C++. e.g. "Decide" can also include deciding to retry the operation with different inputs.

Re: New in Go 1.20: wrapping multiple errors

#73

Post by sidlls »

nhooyr wrote: post #58
sidlls wrote: post #51

"What only matters is the unwrapping procedure and conversion to string because that is what is needed." This, in a nutshell, encapsulates what Go gets wrong about error handling. The simplicity is great; the extreme simplicity at the expense of runtime efficiency and clarity is not . Errors are not just strings . They can (and should) encode information, and the language should support that efficiently. And the mech…

This blog post is inaccurate. The only information an error is required to implement is their string representation. You can add whatever you want on top, there are no further restrictions.

It's true that you can add additional information via structs or even just `fmt.Errorf`, but I disagree that the blog post is inaccurate. Fundamentally Go's error handling is very much string-centered. All the extra encapsulation you add via structs implementing the `error` interface just make things worse, because of the poor design to check those types (`errors.As` is a monstrosity).

Re: New in Go 1.20: wrapping multiple errors

#74

Post by [deleted] »

shakow wrote: post #42
divan wrote: post #18

Earlier quoted context omitted.

> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting)…

> which start make sense as long as you use them and put some thought behind the reasons of the design Hard disagree. I have been using Go at my company for years, and these features still make no sense to me. > lack of enums Not even talking about the eyesore that is the magical const/iota combination (oh yes, your constant definition are scope-dependent, remember to never screw up a copy/paste), go enums are basica…

[deleted]

Re: New in Go 1.20: wrapping multiple errors

#75

Post by cube2222 »

Smaug123 wrote: post #62
cube2222 wrote: post #45

Earlier quoted context omitted.

Implicit interfaces are one of the defining features of the language that make it so great, I love them. Calling them borderline insane without any supporting arguments does make me question whether you ever gave idiomatic Go a chance. What do you dislike about them? Re error handling, I've been looking at the proposals and haven't yet seen a satisfying one. Sure, the current error handling is a bit verbose (three li…

> I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere… This would be absolutely fine, for the reasons you state, if Go made you deal with the error. But because it will silently allow you to completely ignore the error, your statement that it "makes you think about each error" is quite optimistic. In an exceptionful language, the runtime w…

That is a fair point and it's why I use errcheck[0].

[0]: https://github.com/kisielk/errcheck

Re: New in Go 1.20: wrapping multiple errors

#76

Post by foldr »

p-e-w wrote: post #52
bstpierre wrote: post #23

Earlier quoted context omitted.

I think that what you’re talking about might even be the killer feature that is often ignored: the forced simplicity. It’s a simple enough language that you can drop into a codebase and read without having to look up much syntax, assuming you have some familiarity with c-family languages. Yes, there are some weird bits that you have to learn, but the learning curve is very short compared to a lot of other languages.

Indeed, Go is reduced to the bare essentials! That's why it has primitive types representing complex numbers, which maybe 1 in 10,000 projects will use. It doesn't have enums though, because who needs those?

No need to be so salty. No-one is claiming that Go is an ultraminimalist language, just that it's relatively simple compared to most of the alternatives.

Re: New in Go 1.20: wrapping multiple errors

#77

Post by bamboozled »

p-e-w wrote: 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…

Sorry, but what are you talking about? Poorly designed? A lot of incredibly good software is written in Golang and while that might not mean it's the best language ever designed, it would be hard to say it's "poorly designed" based on that fact alone?

Re: New in Go 1.20: wrapping multiple errors

#78

Post by OtomotO »

divan wrote: post #65
OtomotO wrote: post #48

Earlier quoted context omitted.

It's not common in any software I've written or touched in my entire career.

Well, maybe subset of software you written or touched is much smaller than the whole set of software billions of other people wrote or touched.

Oh, without a doubt.

What I mean though: the US isn't the world, even though many people think it is.

And the US date format is among the weirdest I ever encountered.

Super happy I never had to support it. It was enough to support over a dozen different formats at one customer at one point.

Re: New in Go 1.20: wrapping multiple errors

#79

Post by p-e-w »

cube2222 wrote: post #45
p-e-w wrote: 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…

Implicit interfaces are one of the defining features of the language that make it so great, I love them. Calling them borderline insane without any supporting arguments does make me question whether you ever gave idiomatic Go a chance. What do you dislike about them? Re error handling, I've been looking at the proposals and haven't yet seen a satisfying one. Sure, the current error handling is a bit verbose (three li…

> What do you dislike about them [implicit interfaces]?

Implicitly implemented interfaces can lead to problems where you're "implementing" an interface because your methods happen to be named the same, but the functionality doesn't adhere to the contract the interface is supposed to represent. Not every contract can be described by the type system, especially not by a type system as limited as Go's.

Method names like "Write", "Get", or "Execute" are very common, yet in Go you have to be careful because suddenly you're implementing an interface that is intended for things that have nothing to do with what your code actually does.

Simply put, it's an enormous weakening of contract safety, for essentially zero benefit. After all, spelling out that your type implements a certain interface really isn't a lot of work.

Re: New in Go 1.20: wrapping multiple errors

#80

Post by vsnf »

knorker wrote: post #21

When comparing how Go changes with how C++ changes, one gets renewed appreciation for how good of a job the C++ designers are doing. The more Go evolves, the more clear it gets that it has a very poorly designed foundation. I say that as someone who's coded and reviewed a lot of Go code. Maybe they should not have skipped 40 years of language theory when first creating it. It wasn't obvious in the beginning, but now.…

> It wasn't obvious in the beginning, but now...

Was it not obvious at the beginning that this was a bad idea? What was the state of programming languages where consciously tossing out progress was considered not on, its face, insane?

Post reply on HN